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(54) System for controlling the distribution and use of digital works using digital tickets 



(57) A system for controlling the distribution and use 
of digital works (101 ) using digital tickets. In the present 
invention, a "digital ticket" is used to entitle the ticket 
holder to exercise some usage right (102) with respect 
to a digital work. Usage rights are used to define how a 
digital work may be used or distributed. Each usage right 
may specify a digital ticket which must be present before 
the right may be exercised. Digital works are stored in 
repositories which enforce digital works usage rights 
(105) when usage of a digital work is requested by a 
requesting repository (103,104). Each repository has a 
"generic ticket agent" which punches tickets. In some 
instances only the generic ticket agent is necessary. In 
other instances, punching by a "special ticket agent" re- 
siding on another repository may be needed. 
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Description 



The present «n re.ates to the fie,d of distribution and ^^jJ^SS SS^pSSSS^ 
A fundamental issue facing the publishing and 
to prevent the unauthorized and unaccounted dtst " bu *^ based system having the 

published materials are typically distributed ,n a ^^^^f^^ muM a works are all being 
capability to recreate the materials. Audto and for delfcery of the mate- 

The transmission of digital works over networks is commonplace. One such corporati ons and government 

internet is a widespread network facilrty by wh^h ^ 

entities communicate and trade .deas and .nformat.on. Computer bulle J«wb lnfor mation services 

networkssuchas CompuServ and Prodigy allowfor the 

such as Dialog and LEX1S/NEXIS provide databases of current '"'^^.^"^ lnfo l a tion Infrastructure (the 
which will exacerbate the situation is the ^rZ^o^Z^l -e neC rTwi increase many times 

r;< te w^^ 

C ° P t 9 e most straightfon.ard way to curb unaccoun^ 

sion. For existing materials that are distributed in deform ^^e^TJ^e output when copying 
copy protection schemes which limit after 3 P- dete ™ ed 

il^n See provided with the softwareand are ^^-^^ use . This is emp.oyed in 
Yet another scheme is to distribute softwa^, but wh.ch requires key *™ ^ M The 

rr^bt;^^^^^ 

hin t Z*3££ ~~rT : system and method for controlling the use and 

prov.es a system and method asclaimed in A tjcket is an 

A system for controlling the distribution and use of d.grta. works u*n , d.grtai trcke* s d-s 
indicator that the ticket holder has already paid ^ J^J^J ^^IKTSS rights specifying the 
,n the present invention, a "digital ticket" ,s used to ^^^^Sm^^,^ used or distributed. Specific 
requirement of the digital ticket. Usage nghts are used to ^defln how a d.grta worK rr y a 
instances of usage rights are used to indicate a .e art ^ a ^ ticket may be specified 

digital ticket which must be P--nt be ore t * •JJ^ the party that desires a copy of the digital 
inaCopyrightofad,g.ta^^^^^ 

IT-ST™ - 2T work has been made - when " ticket ' s 

•punched" a predetermined number of times, it may ^*^ u °f u rjghts for digita , works. Each repository 
Digital works are stored in repos.tor.es. Reposrtor.es enforce the "^age "gn . a ne cessary. In 

has a "generic ticket agent" which punches tickets. In some ^^^^^^^e6. Punching by a 
other instances, punching by a "special tbket ^entVes^ng on ^^^e\ can help prevent digita, 

Tdlgita. ticket is merely an instance of a digita, work. Thus, a digita, ticket may be distributed among repositories 

in the same fashion as other digital works. _ q .„ h jn tne purc hase of software and prepaid up- 

A digital ticket may be used in many commercal scenanos such as .n the pu jsed For examp , e , a 

S grades. A digfta. ticket may also be used to limit number^ t m e^that a ^ Copy rignt 

will become apparent from the detailed description. 
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A system and method in accordance with the invention will now be described, by way of example, with reference 

" th H 9 rra^ instantiation of the operation of the currently preferred embodiment of 

^ nS? diagram illustrating the various repository types and the repository transaction flow between 

them in the currently preferred embodiment of the present invention. h«H,m«nt nf 

Figure 3 is a block diagram of a repository coupled with a credit server in the currently preferred embod.ment of 

^ P Rg"es t^d4b are examples of rendering systems as may be utilized in the currently preferred embodiment 

° f "S^lESEa contents file layout for an individua. digital work of the digital work of Figure 5 as may be 
utilized in the currently preferred embodiment of the present invention. nracan * 
Figire rt 'illustrates the components of a description block of the currently preferred embedment of the present 

inV8 Fiaure 8 illustrates a description tree for the contents file layout of the digital work illustrated in Figure 5. 

Figure 9 us Ses a portionof a descripfion tree corresponding to the individua. digital work Hlustrated in Figure 6_ 
RrurelOillustratesalayoutforthe rights portion of a description block as may be utilized ,n the current^ preferred 

en ^\u^^X^^ fei n certain d-b.ocks have PRINT usage rights and is used to illustrate "strict" 
^ rSlXST^onents of a repository as are utilized in the current* preferred 

mt ^^SS^S^ functional (logical) components of a reposrtory as are utilized in the currently 

of a usage right in the current, preferred embodiment of 

FTqTr^lsltelhe usage rights grammar of the currently preferred embodiment of the present invention. 
Figure 6 s a flowchart illustrating the steps of certificate delivery, hot.ist checking and performance test ng as 
performed in a registration transaction as may be performed in the current, preferred embodiment of the present 

^Figure 17 is a flowchart illustrating the steps of sessbn information exchange and clock synch,onizat^n as ^rnay 
be performed in the currently preferred embodiment of the present invention, after each repos.tory .n the reg.strat.on 
transaction has successful, completed the steps described in Figure 16. ^„=„„ ^ nri 

Rgure X is fa flowchart illustrating the basic flow for a usage transaction, including the common open.ng and 
closing step as may be performed in the current, preferred embodiment of the present invention 

Figure 1 9 Ts a state diagram of server and client repositories in accordance with a transport protocol ft"™**™ 
moving a [digrtS work from fhe server to the client repositories, as may be performed in the current, preferred embod- 
iment of the present invention. 

OVERVIEW 

A system for controlling use and distribution of digital works is disclosed. The present invention is directed to 
supporting commercial transactions involving digital works. , . u w „„„ roH . t« « riioitai reore- 

Herein the terms "digital work", "work" and "content" refer to any work that has been reduced to a 
sentaflon This wol indude any audio, video, text, or multimedia work and any accompanymg mterpreter (e^sott- 
warS Sat may be required for recreating the work. The term composite work refers to a d.grtal work comprised I of a 
Z ect S ofXr digL works. The term "usage rights" or "rights" is a term which refers to rights granted to a recipient 
Ta Sa Twonl Generally, these rights define how a digital work can be used and if it can be f urther distribute^ Each 
usage rSt mLy have one or more specified conditions which must be satisfied before the nght may 

Rgure 1 to a high level flowchart omitting various details but which demonstrates the basic operafiorv of the Resent 
invenflon Referring to Figure 1 . a creator creates a digital work, step 1 01 The creator will then detenrune appropriate 
SjSJSSi attach them to the digital work, and store them in Reposrtory 1. step 102. The determination of 
ST uTage rights and fees will depend on various economic factors. The digital work remains secure, in Re- 
oositorvTuntTfrequest for access is received. The request for access begins with a session in mat, on by ^antfhe 
repository He e a Repository 2 inimtes a session with Repository 1. step 103. As will be desenbed in greater data.. 
S thTs session inttiationTncludes steps which helps to insure that the respective reposrtor.es are trustworthy. As- 
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.urn*** a session can be established, Repository 2 may then request access to .the J Digital Work for a stated 
purpose step 1 04 The purpose may be, for example, to print the digital work or to obtam a copy of the d.grtal work_ 
TheTurpoTewil. correspond' to a specific usage right. In any event. Repository 1 checks the 
with the digital work to determine if the access to the digital work may be granted, step 1 05. The check of Xbe , usage 
5 riahts essentially involves a determination of whether a right associated with the access request has been attached to 

he session with an error message, step 106. If access is granted, reposrtory 1 transmrts the d.grtal wo* 
2 step 107. Once the digital work has been transmrtted to repository 2, repository 1 and 2 each generate b.ll ng ^for- 
mation for the access which is transmitted to a credit server, step 108. Such double b.ll.ng reporting .s done to .nsure 

10 against attempts to circumvent the billing process. K =~««» annarant 

Figure 2 illustrates the basic interactions between repository types in the present .nvent.on. As w.ll become apparent 
from Figure 2, the various repository types will serve different functions. It is fundamental that repos.tor.es w.ll share 
a core set of functionality which will enable secure and trusted communications. Referr.ng to F.gure 2, a reposrtory 
201 represents the general instance of a reposrtory. The repository 201 has two modes of operafon.j ^ server mode 

is and a requester mode. When in the server mode, the repository will be recerv.ng and processing access requests to 
digital works. When in the requester mode, the repository will be initiating requests to access digital works^ Repository 
201 is general in the sense that its primary purpose is as an exchange medium for digrtal w ° rks ° u " n 9^;° U o J^ 
operation, the repository 201 may communicate with a plurality of other repositor.es, namely authonzat™ reposrtory 
202, rendering repository 203 and master repository 204. Communication between repos.tor.es occurs ut.Hz.ng a re- 

20 pository transaction protocol 205. ^ q r^riMnn 

Communicatbn with an authors 
requiring an authorization. Conceptually, an authorization is a digital certificate such that possession of the ^ert ficate 
^quired to gain access to the digrtal work. An authorization is itself a digrtal work that can be moved between 
repositories and subjected to fees and usage rights conditions. An authorization may be required by both repos.tor.es 

2S involved in an access to a digital work. • ..^w^rv Aewiii 

Communication with a rendering repository 203 occurs in connect.on wrth the rendering of a d.grtal work. As wU 
be described in greater detail below, a rendering repository is coupled with a rendering dev.ce (e.g. a pr.nter dev.ce) 

l ° Tommtm^onrhTmiTter reposrtory 205 occurs in connection with obtaining ^J^^S^^S 
tificalion certificates are the means by which a repository is identified as -trustworthy-. The use of .dentif.cat.on certrf- 
icates is described below with respect to the registration transaction. . . h 

Figure 3 illustrates the repository 201 coupled to a credit server 301. The cred.t server 301 ,s dev.c . whrch 
accumulates billing information for the repository 201. The credit server 301 communicates wrth ^W^" 
Sling transactions 302 to record billing transactions. Billing transactions are reported to a b.ll.ng clearinghouse 303 
by he credit server 301 on a periodic basis. The credit server 301 communicates to the b.ll.ng c.ea nngh °use 303 v,a 
clearinghouse transactions 304. The clearinghouse transactions 304 enable a secure and encrypted transm.ss.on of 
information to the billing clearinghouse 303. 

RENDERING SYSTEMS 

A rendering system is generally defined as a system comprising a repository and a rendering device wbich can 
render a digital work into its desired form. Examples of a rendering system may be a computer system, a d.grtal _aud.o 
system or a printer. A rendering system has the same security features as a repository. The coupl.ng of a render.ng 
repository with the rendering device may occur in a manner suitable for the type of render.ng dev.ce 

Figure 4a illustrates a printer as an example of a rendering system. Relernng to F.gure 4 pnnter ^tem40l has 
contained therein a printer repository 402 and a print device 403. It should be noted that the the <^^*"« 
Printer system401 defines a secure system boundary. Communications within the boundary are assumed to be secure^ 
oTpendfng on the security level, the boundary also represents a barrier intended to prov.de phys.ca 
printer repository 402 is an instantiation of the rendering reposrtory 205 of Figure 2. The printer reposrtory 402 wrt .n 
some ins^nces contain an ephemera, copy of a digital work which remains until it is printed out by the pr.nl ^engine 
403. in other instances, the printer repository 402 may contain digital works such as fonts, wh.ch w.H remain , and can 
be billed based on use. This design assures that all communication lines between pr.nters and pr nt.ng dev ces are 
encrypted, unless they are within a physically secure boundary. This design feature el.m.nates a potent,al faurt point 
through which the digrtal work cou.d be improperly obtained. The printer device 403 represents the pr.nter components 

55 used to create the printed output. . rk0 

Also illustrated in Figure 4a is the repository 404. The repository 404 is coupled to the pr.nter reposrtory 402. The 
repository 404 represents an external repository which contains digital works. 

Figure 4b is an example of a computer system as a rendering system. A computer system may const.tute a mult- 
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function" device since it may execute digital works (e.g. software programs) and display digital works (e.g. a digitized 
SS^STSiS S rendering cLce can be viewed as having its own repository, although only one physical 
reposHory^ needed. Referring to Figure 4b. a computer system 41 0 has contained therein a «P*<*^£^ 
Sv411 The display/execution repository 41 1 is coupled to display device, 41 2 and execution dev.ce 41 3. The dashed 
Sox surrounding £e computer system 41 0 represents a security boundary within which ^^TZ^S 
to oe secure The display/execution repository 411 is further coupled to a credit server 414 to report any fees to be 
billed for access to a digital work and a repository 415 for accessing digital works stored therein. 



STRUCTURF OF DIGITAL WORKS 

Usage rights are attached directly to digital works. Thus, it is important to understands structure <^|**£* 
The structure of a d.grtai work in particular composite digital works, may be natural* organized .nto an acyclic ^structure 
such as a hierarchy For example, a magazine has various articles and photographs wh.cn may have been created 
and arc owned by d.Heren, peLns. Eafh of the articles and photographs may represent a node in a hrerarch^ 
structure Consequently con.ro.s i.e. usage rights, may be placed on each node by the creator. By enabhng control 
and fee billing to be assoculed w.th each node, a creator of a work can be assured that the nghts and fees are not 

CirC rthe nt current.y prc.cr.cd embodiment the t.le information for a digital work is dMded into two files: a ■contents- 
file and a "description tree" ...e From the perspective of a repository, the "contents" file is a stream of addressable 
bytes whoselolat depends comp.e.e.y on the .n.erpreter used to play, display or print the digita. work, ^edesenptron 
Ue filemates ^possible to examuie the „gh,s and fees for a work without reference to the content of the digital wort. 
^kS^dSILl the term description tree as used herein refers to any type of acyclic structure used to represent 

the relationship between the varous components of a digital work. 

Fiaure 5 illustrates the layout of a contents file. Referring to Figure 5. a digital work is comprised of story A 510, 
adveZmen ^^ 511 story B 512 and story C 513. It is assumed that the digital work is stored starting at a rela te 
iZTss To Each of the parts of the digita, work are stored linearfy so that story A 510 is stored at approxjmately 
S eSes l£ So. advertisement 511 at addresses 30,001-40.000, story B 512 at addresses 40,001-60,000 and 
story C 51 3 at addresses 60.001-85K. The detail of story A 510 is illustrated in Figure 6. Refernng , to FW™M» 
A 510 is further broken down to show text 614 stored at address 0-1500. soldier photo 615 at actresses 
15oIlO 000 graphics 616 stored at addresses 10.001-25.000 and sidebar 617 stored address 25.001-30.000. Note 
that the data in the contents file may be compressed (for saving storage) or encrypted (for security). 

From Figures 5 and 6 it is readily observed that a digital work can be represented ^ rt « component parts as a 
hierarchy The description tree for a digital work is comprised of a set of related descriptor blocks (d-blocks). The 
c'ten^ 

701 which is a unique identifier for the work in the repository, a starting address 702 proving the stert address of the 
first bZ of the work a length 703 giving the number of bytes in the work, a rights port.on 704 wherein ttte granted 

706 to t ^n 9 1° me child d-b.ccks. In the currently preferred embodiment, the identifier 701 has two parts. The , fKSt 
part is a unique number assigned to the repository upon manufacture. The second part ,s a unique number assigned 
to me work upon creation. The rights portion 704 will contain a data structure, such as a look-up table, wherein the 
va rousTirnation associated with a right is maintained. The information required by the respective usage nghts is 
described in more detail below. D-blocks form a strict hierarchy. The top d-block of a work has no parent, all othe 6- 
bfoSs have Te parent. The relationship of usage rights between parent and child d*.ocks and how conflicts are 

re Ts d peciSe b otd b S is a "she.," d-b.ock. A she., d-block adds no new content beyond the content of its parts. 
A shell d-block is used to add rights and fee information, typically by distributors of digital works. 

Fiaure 8 illustrates a description tree for the digital work of Figure 5. Referring to Figure 8, a top d-block 820 for 
the d^wo* points to the vals stories and advertisements contained therein, ^^^f^^l 
d-block 821 (representing story A 510), d-block 822 (representing the advertisement 511), d-block 823 (representing 
so story B 512) and and d-block 824 (representing story C 51 3). ro „ rDCQ „ fc , AVl R14 d - 

%he portion of the description tree for Story A 510 is illustrated in Figure 9. D^tock 925 epreserr i s to* .614. d 
block 926 represents photo 615, d-block 927 represents graphics 616 by and d-block 928 represents sidebar 617 
TheHghts portion 704 of a descriptor block is further illustrated in Figure 10. Figure 10 illustrates a 3«h 
is repeated in the rights portion 704 for each right. Referring to Figure 10. each right will have a right code field 1 1050 
55 information fieTd 1052. The right code field 1050 will contain a unique code assigned to a right The stetus 

rnfon^aton field 1052 will contain information relating to the state of a right and the digital work. Such '"formaton « 
indited below in Table 1 . The rights as stored in the rights portion 704 may typical* be .n numerical order based on 
the right code. 
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DIGITAL WORK STATE INFORMATION 


Property 


Value 


Use 


Onnip^-in-Use 

wUL/lwO 111 


Number 


A counter of the number of copies of a work that are in use. Incremented when 
another copy is used; decremented when use is completed. 


1 nan-Period 


Time-Units 


Indicator of the maximum number of time-units that a document can be loaned 
out 


Loaner-Copy 


Boolean 


Indicator that the current work is a loaned out copy of an authorized digital work. 


Remaining-Time 


Time-Units 


Indicator of the remaining time of use on a metered document right. ! 


Document-Descr 


String 


A string containing various identifying information about a document. The exact 
format of this is not specified, but it can include information such as a publisher 
name, author name, ISBN number, and so on. 


Revenue-Owner 


RO-Descr 


A handle identifying a revenue owner for a digital work. This is used for reporting 
usage fees. 


Publication-Date 


Date-Descr 


The date that the digital work was published. 


History-list 


History-Rec 


A list of events recording the repostories and dates for operations that copy, 
transfer, backup, or restore a digital work. \ 
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The approach for representing digtal works by separating description data from content assumes that parts of a 
file are contiguous but takes no position on the actual representation ot content. In particular, it is neutral to the question 
of whether content representation may take an object oriented approach. It would be natural to represent content as 
objects. In principle, it may be convenient to have content objects that include the billing structure and rights information 
that is represented in the d-blocks. Such variations in the design of the representation are possible and are viable 
alternatives but may introduce processing overhead, e.g. the interpretation of the objects. 

Digital works are stored in a repository as part of a hierarchical file system. Folders (also termed directories and 
sub-directories) contain the digital works as well as other folders. Digital works and folders in a folder are ordered in 
alphabetical order. The digital works are typed to reflect how the files are used. Usage rights can be attached to folders 
so that the folder itself is treated as a digital work. Access to the folder would then be handled in the same fashion as 
any other digital work As will be described in more detail below, the contents of the folder are subject to their own rights. 
Moreover, file management rights may be attached to the folder which define how folder contents can be managed. 

ATTACHING USAGE RIGHTS TO A DIGITAL WORK 

It is fundamental to the present invention that the usage rights are treated as part of the digital work. As the digital 
work is distributed, the scope of the granted usage rights will remain the same or may be narrowed. For example, when 
a digital work is transferred from a document server to a repository, the usage rights may include the right to loan a 
copy for a predetermined period of time (called the original rights). When the repository loans out a copy of the digital 
work : the usage rights in the loaner copy (called the next set of rights) could be set to prohibit any further rights to loan 
out the copy. The basic idea is that one cannot grant more rights than they have. 

The attachment of usage rights into a digital work may occur in a variety of ways. If the usage rights will be the 
same for an entire digital work, they could be attached when the digital work is processed for deposit in the digital work 
server. In the case of a digital work having different usage rights for the various components, this can be done as the 
digital work is being created. An authoring tool or digital work assembling tool could be utilized which provides for an 
automated process of attaching the usage rights. 

As will be described below, when a digital work is copied, transferred or loaned, a "next set of rights" can be 
specified. The"next set of rights" will be attached to the digital work as it is transported. 



ss 



Resolving Conflicting Rights 

Because each part of a digital work may have its own usage rights, there will be instances where the rights of a 
-contained part" are different from its parent or container part. As a result, conflict rules must be established to dictate 
when and how a right may be exercised. The hierarchical structure of a digital work facilitates the enforcement of such 
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rules A -strict" rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned 
to the part for ancestor d-b.ocks containing the part and for a„ descender,, flocks. By -nc^«U ^ meant that • 
(1) each of the respective parts must have the right, and (2) any conditions for exercising the right are satisfied 

Talso possible to implement the present invention using a more lenient rule. In the more lenient rule access to 
the ifZ^eiSed to the descendent parts which have the right, but access is denied to the descendents which 

d ° °An example of applying both the strict rule and lenient is illustrated with reference to Figure 11 . Referring to Figure 
11, a roo^bll tToihas child d-b.ocks 1102-1105. In this case, root d-block represents a ™^?£*2 
the child d-blocks 1102-1105 represent articles in the magazine. Suppose that a request .s made to PRINT the digrtal 
worrrepresemed by root d-block 1101 wherein the strict rule is followed. The rights for the root d-block 1101 and child 
^bocks^ 

right? ChiW a-btoVk lTo3 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on 
^Tnde^ 

Under the lenient rule the result would be different. The digital works represented by child d-blocks 1102 and 1105 
rn^d be o fn^ed and the digital work represented by d-block 1104 could be printed so long as the usage fee is paid. 
£j£ d-bicck 1103 could not be printed. This same result would be accomplished under 
the strict rule if the requests were directed to each of the individual digital works. 

The presenTfnvention supports various combinations of allowing and disallowing access. Moreover as w,H be 
desc^bed below he usage rights grammar permits the owner of a digital work to specify r. constraints may be imposed 
o rtne work b >* container pan. The manner in which digital works may be sanctioned because of usage nghts conflicts 
would be implementation specific and would depend on the nature of the d.grtal works. 

REPOSITORIES 

In the description of Figure 2, it was indicated that repositories come in various forms. All ^ te ^"^ e * 
core set of services for the transmission of digital works. The manner in which d.grtal works are exchanged , the basis 
tor alUnaniction between repositories. The various repository types differ in the ultimate functions *at hey ^rtonru 
Repositories may be devices themselves, or they may be incorporated into other systems. An example is the rendering 

so ^^^ZLsoa^ with it a reposrtory identifier. Typica.ty, the reposito* ™«^»£Z*^ m 
number assigned to the repository at the time of manufacture. Each reposrtory will also be classified as being in a 
clasl Certain^ommunications and transactions may be conditioned on a repository being in a 
Articular security class The various security classes are described in greater detail below. t . r ^ tinn 
P Tl^ZSo Xo operation, a reposrtory will require possession of an identification certificate, 1*"^"™ 
certrtta^s are encrypted to prevent forgery and are issued by a Master repository. A master 

San authorizatL aqent to enable repositories to receive digital works. Identification certificates must be updated on 
a period S^S2SJt!rt^ are described in greater detail below with respect to the reg.trat.on trans- 

aCti °A n "repository has both a hardware and functional embodiment The functional ^^^^^SSl 
executing on the hardware embodiment. Alternatively, the functional embodiment may be embedded in the hardware 
embodiment such as an Application Specific Integrated Circuit (ASIC) chip. 

Thrhardware embodiment of a repository will be enclosed in a secure housing which rt compromised, may cause 
the reoostoCo o ^ d^sS.ed The bas* components of the hardware embodiment of a repository are described with 
« etorence To ^ i^e 1 2 ReSrlHg to Figure \i, a repository is comprised of a processing means 1200 

207 c^k 1205 and external interface 1206. The processing means 1200 is compnsed of a processor element 201 
IS oroSssofmemon; 1202 The processing means 1201 provides controller, repository transaction and usage rights 
Z^ Z^ZTJZ\ S9 oL^. Vartous functions in the operation of the repository such as 
decompression of digital works and transaction messages are also performed by the processing means 1200. The 
Pro^ess^ement lid may be a microprocessor or other suitable computing component. The P'<*°*™™™°* 
?M2 w^uld voicallv be further comprised of Read Only Memories (ROM) and Random Access Memories (RAM). Such 
memoTes JS^S^^L instructions utilized by the processor element 1 201 in performing the functions 

Ofth ZstoSsysteml207isfurthercompri S edofdescriptorsto ra ge12 

tree ^£XZ£lT«** the description tree for the digital work and the content storage will store ^the associated 
extern The description tree storage 1 203 and content storage 1 204 need not be of the same type of storage medium, 
no^are'Cn^ S on.the same physical device. So for example, the descriptor storage 1203 may jbej stored on 
a soTd Z storage (for rapid retrieval of the description tree information), while the content storage 1 204 may be on 
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3 tffllMriSI vartous time based conditions for usage rights or tor metering usage fees 
which mavTe associated with the digital works. The clock 1205 will have an uninterruptable power supply, e.g. a 
SS^ToSir^SSn the integrity of the time-stamps. The externa, interface means 1 206 provides tar the signal 
^n^lTihe^SSUitories and to a credit server. The external interface means 1206 provdes for the exchange 
SSS^«5T.SSrd interfaces such as RS-232 or Persona. Computer Manufacturers Card Industry Assoc.at.on 
SpSSSa boards or FDD.. The external interface means 1206 may also provide network connectmty. 
( T^unctona I ernbodimen, of a repository is described with reference to Figure 1 3. Referring to Figure 1 3 the 
funeral SESmS .s compr,sed of an operating system 1301, core reposttory services 1302, usage transactor, 
hand™ 13? ^ repertory specific functions 1304 and a user interface 1305. The operating r^™**"*?. 
to thTrepcSory and would typically depend on the type of processor being used. The WOU,d 
also provide the bas.c servces for controlling and interfacing between the bas,c components of the reposrto^ 

The core repository servces 1302 comprise a set ol functions required by each and every repository. The core 
reoostorv servfcTs delude the session initiation transactions which are defined in greater deta.l below This set 
ofTerSs 1Z he udes a generc fcket agent which is used to "punch" a digital ticket and a gener.c author.zat.on 
s^e7 or prt ess.ng aumoLt^n specimens. Digital tickets and authorizations are specie mechan.sms for con- 
uomna the d^tribut.on ano use o. d,g.tal works and are described in more detail below. Note that coupled to the core 
Z^SSS^ b p.uram y onden,...ca.K>n certificates 1306. The identification certificates 1306 are requ.red to 

^ Thetsage CsacuS'Zdle.s 1 303 comprise functionality for processing access requests to digita. works and 
for b^ng feel bled^ access The usage transactions supported wi.. be dfflerent for each repository type. For ex- 
ample, it may not be necessary lor some repositories to handle access requests for d.grtal works. _ 

The repository specific funC.ona.ity 1304 comprises functionality that is urnque to a reposrUxy. F <» *• 
maS torreP^^ 

specific functionality i 304 would include the user interface implementation for the repository. 

Repository Security Clssses 

For some diqital works the losses caused by any individual instance of unauthorized copying is insignificant and 
the ^^STc^m Hes in assuring the convenience of access and Overhead bi.ling. .n such cases, simple 
and tslpeZe handheld repositories and network-based workstations may be suitable repos.tor.es, even though the 

^X^^^^L as a digna. copy of a firs, run movie or a bearer bond or stock 
certtfbate would be of very high value so that it is prudent to employ caution and fairly elaborate secunty measures to 
ensure ^IhaTthVy are not copied or forged. A repository suitable for ho.ding such a digita. work could have elaborate 
measures for ensuring physical integrity and tor verifying authorization before use. 

By arranging a universal protocol, all kinds of repositories can communicate with each other in pnnciple. H ^ 
creatorso^ 

is high enough. For this reason, document repositories have a ranking system for classes and levels of secunty. The 
security classes in the currently preferred embodiment are described in Table 2. 



TABLE 2 


REPOSITORY SECURITY LEVELS 


Level 


Description o1 Security 


0 


Open system. Document transmission is unencrypted. No digital certificate is requ.red for ^<**"- 
The securityofthesystemdepends mostly on user honesty, since only modest knowledgemay ^be needed 
to circumvent the security measures. The repository has no provisions for preventing un a^or.zed 
programsfromrunningandaccessingorcopyingfiles. The system does not prevent the use of removable 
storage and does not encrypt stored files. 


1 


Minimal security. Like the previous class except that stored files are m.n.mally encrypted, .nclud.ng ones 
on removable storage. 


2 


Basic security. Like the previous class except that special tools and knowledge are requ.red to 
compromise the programming, the contents of the repository, or the state of the clock. All d|9'tal 
communications are encrypted. A digital certificate is provided as identification. Med.um level encrypt.on 
is used Repository identification number is unforgeable. 
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REPOSITORY SECURITY LEVELS 


Level 


Description ot Security 


3 


General security. Like the previous class plus the requirement of special tools are needed to. 

. . .. . „ » ~r./-r>#ritir>ri i« ii^(»d on all transmissions. Password 

the physical integrity of the repository and that modest encryption is usea on an xransinioa 

protection is required to use the local user interface. The digital clock system cannot be reset without 
authorization. No works would be stored on removable storage. When executing works as f™*™** 
runs them in their own address space and does not give them direct access to any file storage or other 
memory containing system code or works. They can access works only through the transmission 
transaction protocol. , 


4 


Like the previous class except that high level encryption is used on an communicdugru,. o« 

usc^ ?o record attempts at physical and electronic tampering. After such tampering, the repos.tory will 

™t nort nrm nthf>r truncations until it has reported such tampering to a designated server 


5 


Like the previous class except that if the physical or digital attempts at tampering exceed some preset 
^csho«stha, threaten the physical integrity of the repository or the integrity of digital and cryptographic 
Lr»rs then the repository will save only document description records of hetory but w.11 erase or destroy 

udTnuid ii iv.i u j ..-^n.rtiiimic nartv t a so modifies anv 

any diqrtal identifiers that could be misused if released to an unscrupulous party It also mc ™ °» a n y 
certificates of authenticity to indicate that the physical system has been compromised. It also erases the 
contents of designated documents. m , — . 


6 


Like the previous class except that the repository will attempt wireless communication to report tampering 
and will employ noisy alarms. : — — 


10 


Th,s would correspond to a very high level of security. This server would maintain cons ^ n < 
commun.cat.ons to remote security systems reporting transactions, sensor readings, and attempts to 
circumvent security ■ 
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The charactenzation of security levels described in Table 2 is not intended to be fixed. More important is the idea 
of halg 'TtlveTsTcZy levels tor different repositories. It is anticipated that new security classes and requirements 
will evolve according to social situations and changes in technology. 

Repository User Interface 

A user interface is broadly defined as the mechanism by which a user interacts with a repository in order to invoke 
tranictionl o gain access to a digital work, or exercise usage rights. As described above, a repository may be em- 
oSS * vaLTforms. The user interface for a repository will differ depending on the particular embodiment The 
ustn^dace may be a graphical user interface having icons representing the digital works and ^^^^ 
th^mTy be Performed The user interface may be a generated dialog in which a user is prompted for '"^on_ 

The use ^intcrfTc rtsc.f need not be part of the repository. As a repository may be embedded in some 
the user interface may merely be a part of the device in which the repository is embedded. For example the repos.tory 
could be emSde^n ^card" that is inserted into an avai.ab.e slot in a computer system. The user interface may be 
a cwol7™ of a display, keyboard, cursor control device and software executing on the computer sys em. 

At a m^lum the user interface must permit a user to input information such as access requests and a pha 
nume ic da aTnd provide feedback as to transaction status. The user interface will then cause the repository to initiate 
rsu"ab.eTransa P c ;^ 
that a repository will provide. 

CREDIT SERVERS 

In the present invention, fees may be associated with the exercise of a right. The requirement for payment of fees 
is described wT e^ version of a usage right in the usage rights language. The recording and reporting of suchfees 
s perfc ^ m7d by me credit server. One of the capabilities enabled by associating fees w, h rights ,s the ^possrb «) r of 
support ng a Sde range of charging models. The simplest model, used by conventional sottware.^ that there .a 
sinqle^e atthe time of purchase after which the purchaser obtains unlimited rights to use he work as often , and for 
as fonq as he of she wante. Alternative models, include metered use and variable fees. A s.ng.e work can hav .different 
feestordmeren^ 
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or including it in a newly created work. A key to these alternative charging models is to have a low overhead means 
r^i ^ctahiiQhinn fpes and accounting for credit on these transactions. 

7££^E£ZL^ system that reliably authorizes and records these transactions so that ees are 

bille^Xa^ 

UansS^as they occur. As a result, bills may be generated and accounts reconciled. Preferably, the credit server 
wouSSoTeTe ee'Lsactions and periodically communicate via a network wrth the billing <»™*™*^ 
Nation In such an embodiment, communications with the billing clearinghouse would be encrypted lor mtegnty and 
seS' reason another embodiment, the credit server acts as a "debit card" where transacts occur ,n rea.- 

"^cfe^^risTm" ised of memory, a processing means, a clock, and interface means for coupling to a re- 
positony and a financial insStution (e.g. a modem). The credrt server will also need to have security and 
fSS£. These elements are essentially the same elements as those of a repertory ^""J**"^ 
be both a repository and a credit server, provided that it has the appropriate process.ng elements for carrying out the 
conesPond!ng functions and protocols. Typically, however, a credrt server would be a card-seed system .n the pos- 
sessTof the owner of the credit. The credit server is coupled to a repository and would interact via ^^c«l trans- 
actions as described below, .nteractions with a financial institution may occur via protocols established by the f.nancia. 
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T Z c^nTy preferred embodiment credit servers associated with both the server and the reposi ory report .he 
financia]transactiontothebi..ingclearinghouse. For example, when a digital work is cop.ed by one reposrtory to another 
zo cTa^e creorsTlrs coupled to each of the repositories will report the transaction to the bilhng clearinghouse. This 
s de "ab^n that it insures^ a transaction will be accounted for in the event of some break ,n ^»^«^ 
between a credrt server and the billing clearinghouse. However, some implementations may embody onty < s,n gle 
credrt server reporting the transaction to minimize transaction processing at the nsk of losing some transacts. 

25 USAGE RIGHTS LANGUAGE 

The present invention uses statements in a high level "usage rights language" to define rights associated with 
diaital works and their parts. Usage rights statements are interpreted by reposrtones and are used to determine what 
UanicTonl can be successfully carried out for a digital work and also to determine parameters for those 
For Sample sentences in the language determine whether a given digrtal work can be copied when and how rt can 
be used and what fees (rt any) are to be charged for that use. Once the usage rights statements are generated, they 
are encoded in a suitable form for accessing during the processing ol transactions. 

Deling usage rights in terms of a language in combination wrth the hierarchical represents , on , of a 
enables the support of a wide variety of distribution and fee schemes. An example .s the ability to atte* mult.pe 
veSoTs of a S to a work. So a creator may attach a PRINT right to make 5 copies for $1 0.00 and a PRINT r.gh Xo 
make un.?mrte^ ^copies for $100.00. A purchaser may then choose which option best fits his needs. Another example 
Islhat rightandZs are additive. So°n the case of a composite work, the rights and fees of each of the components 
works is used in determining the rights and fees for the work as a whole. transactional 
The basic contents of a right are illustrated in Figure 14. Referring to Figure 14, a right 1450 has a transactional 
comlonenn 451 and a specifications component 1 452. A right 1 450 has a label (e.g. COPY or PRINT) wh.chjnd,cates 
^hTuse o?d stribution prMleges that are embodied by the right. The transactional component 1451 corresponds to a 
particular way n which a digL work may be used or distributed. The transactional component 1451 is typ-calfy em- 
S nXe instructions in a repository which implement the use or distribution priv ^^eges forth. , nght^he 
specifications components 1452 are used to specify conditions whichmust be satisfied pro-to the 
45 oMo designate various transaction related parameters. In the currently preferred embodiment these sp°cmcat.ons 
fnc ude Sy count 1453, Fees and Incentives 1454, Time 1455, Access and Securrty 1456 and Control 145^ Each 
of these specifications will be described in greater detail below with respect to the language grammar element^ 

The usage rights language is based on the grammar described below. A grammar is a convenient means for 
definin h gSs e eguence ofsymbo.s for a language. In describing the grammar ^e notation ^ J — 
so distinct choices among alternatives. In this example, a sentence can have either an a , b or c _ It must incluae 
exactly one of them. The braces {} are used to indicate optional items. Note that brackets, bars and braces are used 
to describe the language of usage rights sentences but do not appear in actual sentences in the language 

.Tanentneses are' part of the usage rights language. Parentheses are used to group rterns together in 
Hsts The notation (x*) is used to indicate a variable length list, that is, a list containing one or more .terns of type x. 
55 The notation (x)* is used to indicate a variable number of lists containing x. 

Keywords in the grammar are words followed by colons. Keywords are a common and very special case in he 
languagl They are oTten used to indicate a single value, typically an identifier. In many cases, the keyword and the 
pTrameter are entirely optional. When a keyword is given, it often takes a single identifier as rts value. In some cases, 
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^ rr^H^ZS^ is spewed in an hou^inute.seconds (or «ss) rep~^ 
zone"ndicators e g PDT for Pacific Daylight Tune, may also be specified. Dates are represented as year/ month/day 
(r^YY/SM^D) Note that these time and date representations may specify moments in time or umts of t,me 
Monev units are specified in terms of dollars. 

Rnally, in the usage rights .anguage, various things" will need to interact with each ™£ J£ 
of a usage right may specify a bank account, a digrtal ticket, etc. . Such things need to be ,denff.ed and are speeded 
herein using the suffix "-ID." - 

The Usage Rights Grammar is listed in its entirety in F.gure 1 5 and is described below. 

GrammaT element 1 501 "Digital Work Rights: = (Rights*)" define the digital work nghts as a set o ' "J^Tta 
set of rights attached to a digital work define how that digital work may be transferred, ^^^SSSi 
set of rights will attach to the entire digital work and in the case of compound d.grtal works, each of the components of 
thP diaital work The usaqe rights of components of a digital may be different. 

^2a^l2^602 9 -RhjM: = (Right-Code {Copy-Count} t^ S ^> h ^^"^ y ^ 0 
{Fee-Spec})" enumerates the content of a right. Each usage right must specify a nght code. Each ght may ateo 
optJnany specify conditions which must be satisfied before the right can be exercised. These «^<»H 
coJnt control time access and fee conditions. In the currently preferred embodiment, for the opt.onal elements the 
Sin" Tde^Tapply: copy count equals 1 , no time limit on the use of the right, no access tests or a securrty level 
"d to use the right ana no fee is required. These conditions wi.l each be desenbed in greater ^ »£j 

It is important to note that a digital work may have multiple versions of a right, each having the same nght code. 
The multiple version would provide alternative conditions and fees for accessing the digital work 

Grammar e.ement 1503 "Right-Code : = Render-Code I Transport-Code I "•^TTT^'^P^^ 
Works- Code Configuration-Code" distinguishes each of the specific rights into a particular 

right is identified by distinct right codes). In this way, the grammar provides a catalog of possible nghts that car .be 
assocLied with parts of digital works. In the following, rights are divided into categories for convenience ,n descnbing 

'^"Grammar element 1 504 "Render-Code : = [Play : (Player: P,ayer-.D } IPrint: { Printer: P^ D j^*" 

rights all involving the making of ephemeral, transitory, or non-digital copies of the d.grtal work. After use the copies 

are erased. 

. P ,ay A process of rendering or performing a digital work on some processor. This include ^"ch things as 
playing digital movies, playing digital music, playing a video game, running a computer program, or d.s- 

Dlavinq a document on a display. . 

. Print To render the work in a medium that is not further protected by usage rights, such as printing on paper. 

Grammar e.ement 1505 "Transport-Code : = [Copy.Transfer.Loan < Re ™ inin f ^ 
flNext-Copy Rights: Next-Set of Rights)}" lists a category of rights involving the making of persistent, "sable cop es 
of ^fdigtel work on other repositories. The optional Next-Copy-Rights determine the rights on the work afte cj. 
^nsportec I "his is not specified, then the rights on the transported copy are the same as on the ong.nal. The ^optional 
Re^JS'Rights specify the rights that remain wrth a digital work when it is loaned out. If this ,s not specified, then 
the default is that no rights can be exercised when it is loaned out. 

• Copy Make a new copy of a work 

• Transfer Moving a work from one repository to another. 

• Loan Temporarily loaning a copy to another repository for a specified period of time. 

Grammar element 1506 "Flle-Management-Code : = Backup < B ~™P-C^^^ 
Restore I Delete I Folder I Directory {Name: Hide-Local I Hide - Remote}{Parts:H,de-Local I H.de-Remote} lists 
a category of rights involving operations for file management, such as the making of backup copies to protect the copy 

S ° ° W ^yt« 

catastrophic failure of equipment. However, the making of uncontrolled backup cop.es ,s inherently at odds w,th the 
STfty^nS usage since an uncontrolled backup copy can be kept and then restored even after the authonzed 

55 ^TrFSmanagement rights enable the making and restoring of backup copies in a way ^at respects usag^ , rights 
honoring the requirements of both the copy owner and the rights grantor and revenue owner Backup cop,, esof wo k 
desSons (including usage rights and fee data) can be sent under appropriate protocol and usage ngh U ; central to 
othe document repositories of sufficiently high securrty. Further rights permit organizat.on of d,gital works ,nto folders 
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which themselves are treated as digital works and whose contents may be "hidden 0 from a party seeking to determine 
the contents of a repository. 

• Backup To make a backup copy of a digital work as protection against media failure. 
5 • Restore To restore a backup copy of a digital work. 

• Delete To delete or erase a copy of a digital work. 

• Folder To create and name folders, and to move files and folders between folders. 

• Directory To hide a folder or its contents. 

10 Grammar element 1 507 "Derivative- Works-Code: [Extract I Embed I Edit {Process: Process-ID}] (Next-Copy- 

Rights : Next-Set-of Rights)" lists a category of rights involving the use of a digital work to create new works. 

• Extract To remove a portion of a work, for the purposes of creating a new work. 

• Embed To include a work in an existing work. 

is • Edit To alter a digital work by copying, selecting and modifying portions of an existing digital work. 

Grammar element 1508 "Configuration-Code: = Install I Uninstall" lists a category of rights for installing and 
uninstalling software on a repository (typically a rendering repository.) This would typically occur for the installation of 
a new type of player within the rendering repository. 



20 



> Install: To install new software on a repository. 

• Uninstall: To remove existing software from a repository. 

Grammar element 1509 "Next-Set-of -Rights : = {(Add : Set-Of-Rights)} {(Delete: Set-Of-Rights)} {(Replace: 
2S Set-Of-Rights)} {(Keep: Set-Of-Rights)} " defines how rights are carried forward for a copy of a digital work. If the 
Next-Copy-Rights is not specified, the rights for the next copy are the same as those of the current copy. Otherwise, 
the set of rights for the next copy can be specified. Versions of rights after Add: are .added to the current set of rights. 
Rights after Delete: are deleted from the current set of rights. If only right codes are listed after Delete:, then all versions 
of rights with those codes are deleted. Versions of rights after Replace: subsume all versions of rights of the same type 
30 in the current set of rights. 

If Remaining-Rights is not specified, then there are no rights for the original after all Loan copies are loaned out. 
If Remaining-Rights is specified, then the Keep: token can be used to simplify the expression of what rights to keep 
behind. A list of right codes following keep means that all of the versions of those listed rights are kept in the remaining 
copy. This specification can be overridden by subsequent Delete: or Replace: specifications. 
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Copy Count Specification 



For various transactions, it may be desirable to provide some limit as to the number of "copies" of the work which 
may be exercised simultaneously for the right. For example, it may be desirable to limit the number of copies of a digital 
40 work that may be loaned out at a time or viewed at a time. 

Grammar element 1510 "Copy-Count : = (Copies: positive-integer I 0 I unlimited)" provides a condition which 
defines the number of "copies" of a work subject to the right . A copy count can be 0, a fixed number, or unlimited. The 
copy-count is associated with each right, as opposed to there being just a single copy-count for the digital work., The 
Copy-Count for a right is decremented each time that a right is exercised. When the Copy-Count equals zero, the right 
45 can no longer be exercised. If the Copy-Count is not specified, the default is one. 

Controi Specif/cation 

Rights and fees depend in general on rights granted by the creator as well as further restrictions imposed by later 
so distributors. Control specifications deal with interactions between the creators.and their distributors governing the im- 
position of further restrictions and fees. For example, a distributor of a digital work may not want an end consumer of 
a digital work to add fees or otherwise profit by commercially exploiting the purchased digital work. 

Grammar element 1511 "Control-Spec : = (Control: {Resectable I Unrestrictable} {Unchargeable I Charge- 
able})" provides a condition to specify the effect of usage rights and fees of parents on the exercise of the right. A 
55 digital work is restrictable if higher level d-blocks can impose further restrictions (time specifications and access spec- 
ifications) on the right. It is unrestrictable if no further restrictions can be imposed. The default setting is restrictable. 
A right is unchargeable if no more 1ees can be imposed on the use of the right. It is chargeable if more fees can be 
imposed. The default is chargeable. 
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Time Specification 

It is often desirable to assign a start date or specify some duration as to when a right may be exercised. Grammar 
.ipmlnt Ysi2 -T Zsl • = ({Fixed-Interval I Sliding-lnterval I Meter-Time} Until: Expiration-Date)' provides 
s ^H^^ESS^i the exercise of a right. Rights may be granted for a specified time. Different kinds 
S ZTw£Em are appropriate for different kinds of rights. Some rights may be exerased during , a fixed and 
tZSSSSL Some rights may be exercised for an interval that starts the first time 
hv .some transaction Some riqhts may be exercised or are charged according to some kind of metered time, wnicn 
ma^e sP^nto ! £J£ TSteLis. Fo" examp.e. a right to view a picture for an hour might be spiff into s,x ten minute 
10 viewings or four fifteen minute viewings or twenty three minute viewings. 

The terms "time" and "date" are used synonymously to refer to a moment m time. There are several kinds 01 time 
speJ^Sns Each specification represents some limitation on the times over ^^^S^S^J^ 
Expiration-Date specifies the moment at which the usage right ends. For example f Ihe E x P>rat.on-Date «. Jan 
19g5" then the right ends at the first moment of 1995. If the Expiration-Date is specified as 'forever , the the Rights 
l^fnterprete.; f ^continuing without end. if only an expiration date is gh,en, then the right can be exercised as often 

38 d £ a ™^^^ : = "™ — Time " * US6d to definS 3 ^ — ^ 

mn8 G Zl?rmTnt e T££SS£L : interval: Use-Duration" * used to define an ****** 
■ooen [ )7Z It ime U sets Lts on a continuous period of time over which the contents are accessible period starts 
oTthe Slc^s and ends after the duration has passed or the expiration date ^SSjJ^^S 
For example, if the right gives 10 hours of continuous access, the use<iurat.on would begin when the first access was 

^V^rl^ZTs "Meter-Time: = Time-Remaining: Remaining-Use" is used to define a "meter tirne^ 
that fs a measure of the time that the right is actually exercised. It differs from the Sliding-lnterval specification ,n that 
^ t im th^Uhe ite. work is in use need not be continuous. For example, if the rights 9™™^™.^*«™«* e 
l^l TcoM be spread out over a month. With this specification, the rights can be exercised until the metertime 
is exhausted or the expiration date is reached, whichever comes first. 
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30 Remaining-Use: = Time-Unit 

Start-Time: = Time-Unit 
Use-Duration: = Time-Unit 
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All of the time specifications include time-unit specifications in their ultimate instantiation. 
Security Class and Authorization Specification 

The present invention provides for various security mechanfcms to be introduced into a distribution ^or use scheme 
rvammar element 1516 " Access-Spec :=({SC: Security-Class} {Authorization: Authorization.lD } {Other-Author 
f tZ? A^^^AD^cH^cietAD))' provides a means for restricting access and transmission. Access 
^^^sT^^^ S cLTfor a repository to exercise a right or a required authorizafion test 

^ ^keyw^-SC:" is used to specify a minimum security level for the repositories involved in the access, if "SC: 

wo* The opTonal "Other-Authorization: " keyword is used to specify required authorizations on the other repository 

th The oSonal "Ticket " keyword specifies the identity of a ticket required for the transactbn. A transaction involving 
digital Tmus™a£ an appropriate digffa. ticket agent who can "punch" or otherwise validate the ficket before 
so the transaction can proceed. Tickets are described in greater detail below. rannaiinn , 
In a transaction involving a repository and a document server, some usage rights may require that the repository 
m^uSS^SSJL. mat the server have some authorization, or that both repositories have 
feTentt authorizations. Authorizations themse.ves are digital works (hereinafter referred to as an authonz ation ot.ec ) 
S can be moved between repositories in the same manner as other digital works. Their copying and t»«™£» 
55 subject tothT same rights and fees as other digital works. A repository is said to have an authorization if that author- 

^^S^S^Z^^ — a source other than the document serve ; 
An authorization object referenced by an Authorization-ID can contain digital address information to be used to set up 
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a communications link between a repository and the authorization source. These are analogous to phone numbers. 
For such access tests, the communication would need to be established and authorization obtained before the nght 
could be exercised. 

For one-time usage rights, a variant on this scheme is to have a digital ticket. A ticket is presented to a digital ticket 
s agent whose type is specified on the ticket. In the simplest case, a certified generic ticket agent, available on all 
repositories is available to "punch" the ticket. In other cases, the ticket may contain addressing information for locating 
a 'special" ticket agent. Once a ticket has been punched, it cannot be used again for the same kind of transaction 
(unless it is unpunched or refreshed in the manner described below.) Punching includes marking the ticket with a 
timestamp of the date and time it was used. Tickets are digital works and can be copied or transferred between repos- 
10 itories according to their usage rights. 

In the currently preferred embodiment, a "punched" ticket becomes "unpunched" or "refreshed when it is copied 
or extracted The Copy and Extract operations save the date and time as a property of the digital ticket. When a ticket 
agent is given a ticket, it can simply check whether the digital copy was made after the last time that it was punched. 
Of course, the digital ticket must have the copy or extract usage rights attached thereto, 
is The capability to unpunch a ticket is inportant in the lollowing cases: 

• A digital work is circulated at low cost with a limitation that it can be used only once. 

. A digital work is circulated with a ticket that can be used once to give discounts on purchases of other works. 

. A digital work is circulated with a ticket (included in the purchase price and possibly embedded in the work) that 

20 can be used for a future upgrade. 

In each of these cases, if a paid copy is made of the digital work (including the ticket) the new owner would expect 
to get a fresh (unpunched) ticket, whether the copy seller has used the work or not. In contrast, loaning a work or simply 
transferring it to another repository should not revitalize the ticket. 



25 



Usage Fees and Incentives Specification 



The billing for use of a digital work is fundamental to a commercial distribution system. Grammar Element 1517 
•Fee-Spec: = {scheduled-Discount> Regular-Fee-Spec I Scheduled-Fee-Spec I Markup-Spec" provides a range 
30 of options for billing for the use of digital works. 

A key feature of this approach is the development of low-overhead billing for transactions in potentially small 
amounts Thus, it becomes feasible to collect fees of only a few cents each for thousands of transactions. 

The grammar differentiates between uses where the charge is per use from those where it is metered by the time 
unit. Transactions can support fees that the user pays for using a digital work as well as incentives paid by the right 
35 grantor to users to induce them to use or distribute the digital work. 

The optional scheduled discount refers to the rest of the fee specification-discounting it by a percentage over 
time If it is not specified, then there is no scheduled discount. Regular fee specifications are constant over time. 
Scheduled fee specifications give a schedule of dates over which the fee specifications change. Markup specifications 
are used in d-blocks for adding a percentage to the fees already being charged. 
40 Grammar Element 1518 "Seheduled-Discount:= (Scheduled-Discount: (Time-Spec Percentage)*) A Sched- 

uled-Discount is a essentially a scheduled modifier of any other fee specification for this version of the right of the 
digital work (It does not refer to children or parent digital works or to other versions of rights.). It is a list of pairs of 
times and percentages. The most recent time in the list that has not yet passed at the time of the transaction is the 
one in effect The percentage gives the discount percentage. For example, the number 10 refers to a 10% discount 
45 Grammar Element 1519 -Regular-Fee-Spec : = ({Fee: I Incentive: } [Per-Use-Spec I Metered-Rate-Spec I 

Best-Price-Spec I Call-For-Price-Spec ] (Min: Money-Unit Per: Time-Spec}{Max: Money-Unit Per: Time-Spec) 
To- Account-ID)" provides for several kinds of fee specifications. 

Fees are paid by the copy-owner/user to the revenue-owner if Fee: is specified. Incentives are paid by the revenue- 
owner to the user if Incentive, is specified. If the Min: specification is given, then there is a minimum fee to be charged 
so per time-spec unit for its use. If the Max: specification is given, then there is a maximum fee to be charged per time- 
spec for its use. When Fee: is specified, Account-ID identifies the account to which the fee is to be paid. When In- 
centive is specified, Account-ID identifies the account from which the fee is to be paid. 

Grammar element 1 520 "Per-Use-Spec: = Per-Use: Money-unit" defines a simple fee to be paid every time the 
right is exercised, regardless of how much time the transaction takes. 
ss Grammar element 1 521 "Metered-Rate-Spec : = Metered: Money-Unit Per: Time-Spec" defines a metered-rate 

fee paid according to how long the right is exercised. Thus, the time it takes to complete the transaction determines 

thB f ©6 

Grammar element 1522 "Best-Pr ice-Spec : = Best-Price: Money-unit Max: Money-unit" is used to specify a 
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best-price that is determined when the account is settled. This specification is to accommodate special deals, rebates, 
and pricing that depends on information that is not available to the repository. All fee specifications can be combined 
with tickets or authorizations that could indicate that the consumer is a wholesaler or that he is a preferred customer, 
or that the seller be authorized in some way. The amount of money in the Max: field is the maximum amount that the 
5 use will cost. This is the amount that is tentatively debited from the credit server. However, when the transaction is 
ultimately reconciled, any excess amount will be returned to the consumer in a separate transaction. 

Grammar element 1523 "Ca I l-For- Price-Spec: = Call-For-Price n is similar to a "Best-Price-Spec" in that it is 
intended to accommodate cases where prices are dynamic. A Call-For-Price Spec requires a communication with a 
dealer to determine the price. This option cannot be exercised if the repository cannot communicate with a dealer at 
10 the time that the right is exercised. It is based on a secure transaction whereby the dealer names a price to exercise 
the right and passes along a deal certificate which is referenced or included in the billing process. 

Grammar element 1524 "Scheduled-Fee-Spec: = (Schedule: (Time-Spec Regular- Fee-Spec)*) " is used to pro- 
vide a schedule of dates over which the fee specifications change. The fee specification with the most recent date not 
in the future is the one that is in effect. This is similar to but more general than the scheduled discount. It is more 
is general, because it provides a means to vary the fee agreement for each time period. 

Grammar element 1525 -Markup-Spec: = Markup: percentage To: Account-ID" is provided for adding a per- 
centage to the fees already being charged. For example, a 5% markup means that a fee of 5% of cumulative fee so 
far will be allocated to the distributor. A markup specification can be applied to all of the other kinds of fee specifications. 
It is typically used in a shell provided by a distributor. It refers to fees associated with d-blocks that are parts of the 
20 current d-block. This might be a convenient specification for use in taxes, or in distributor overhead. 

REPOSITORY TRANSACTIONS 

When a user requests access to a digital work, the repository will initiate various transactions. The combination 
25 of transactions invoked will depend on the specifications assigned for a usage right. There are three basic types of 
transactions Session Initiation Transactions, Financial Transactions and Usage Transactions. Generally, session ini- 
tiation transactions are initiated first to establish a valid session. When a valid session is established, transactions 
corresponding to the various usage rights are invoked. Finally, request specific transactions are performed. 

Transactions occur between two repositories (one acting as a server), between a repository and a document play- 
30 back platform (e.g. for executing or viewing), between a repository and a credit server or between a reposrtory and an 
authorization server When transactions occur between more than one repository, it is assumed that there is a reliable 
communication channel between the repositories. For example, this could be a TCP/IP channel or any other commer- 
cially available channel that has built-in capabilities for detecting and correcting transmission errors. However, it is not 
assumed that the communication channel is secure. Provisbns for security and privacy are part of the requirements 
35 for specifying and implementing repositories and thus form the need for various transactions. 

Message Transmission 

Transactions require that there be some communication between repositories. Communication between reposi- 
40 tories occurs in units termed as messages. Because the communication line is assumed to be unsecure, all commu- 
nications with repositories that are above the lowest security class are encrypted utilizing a public key encryption 
technique Public key encryption is a well known technique in the encryption arts. The term key refers to a numeric 
code that is used with encryption and decryption algorithms. Keys come in pairs, where "writing keys' are used to 
encrypt data and "checking keys" are used to decrypt data. Both writing and checking keys may be public or private. 
45 Public keys are those that are distributed to others. Private keys are maintained in confidence. 

Key management and security is instrumental in the success of a public key encryption system. In the currently 
preferred embodiment, one or more master repositories maintain the keys and create the identification certificates 
used by the repositories. 

When a sending repository transmits a message to a receiving repository: the sending repository encrypts all of 
so its data using the public writing key of the receiving repository. The sending repository includes its name, the name of 
the receiving repository, a session identifier such as a nonce (described below), and a message counter in each mes- 
sage 

In this way, the communication can only be read (to a high probability) by the receiving repository, which holds the 
private checking key for decryption. The auxiliary data is used to guard against various replay attacks to security. If 
55 messages ever arrive with the wrong counter or an old nonce, the repositories can assume that someone is interfering 
with communication and the transaction terminated. 

The respective public keys for the repositories to be used for encryption are obtained in the registration transaction 

described below. 
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Session Initiation Transactions 

A usaoe transaction is carried out in a session between repositories. For usage transactions involving more than 
one reposK o Tor ZancZ transactions between a reposito ry and a credrt server, a registration transart-on * ^per^ 
A second transaction termed a login transaction, may also be needed to init,ate the sess.on. The goal of the 
Srat^nSTsai ton SmSLi a secure channel between two repositories who know each others .dentrt-es^ As 
KtiS^^oommuni^ channel between the repositories is reliable but not secure, there ,s a nskthat 
a non-repository may mimic the protocol in order to gain illegitimate access to a repository. 

?hf^aSration transaction between two repositories is described with respect to F.gures 16 and 17. The steps 
de sTbe Z SmCersp "ctive of a Teposrtory-1 ■ registering its identity wrth a depository -2". The reg.st^on ^must 
h^vmmetnla so the same set ol steps will be repeated for repository-2 registenng rts identity wrth repository-^ 
ReferZ to Hgure £ reposrtory-1 first'generates an encrypted registration identifier, step 1601 and then generates 
TfeoiXa ion message step 1602. A registration message is comprised of an identify of a master repository, the 
VS^£££?£& repository-? and an encrypted random registration identifier. The 

T«!^!t«rt hw the master repository in its private key and attests to the fact that the repository (here reposrtory-1 ) is 
a bon EH ££L7Z de P ntSon ceLate also contains a public key for the repository, the repositonr^cur-ty 
feve I an a Settemp (indicating a time after which the certrticate is no longer valid.) The registration ,dentrt.e ^.s a 
n^mbefqeneTated b he repository for this registration. The registration identifier is unique to the sess.on and is 
encrvote? in repository-1 "s prtvate key. The registration identifier is used to improve securrty of authentication by to- 
SS^rSiSS o7communications based attacks. Repository-1 then transmits the reg.stration message to repos- 

% 2 pon e r P ece^g the registration message, repository-2 determines if it has the needed public key for 
repo^Sry, Itep 16?>4. If repository-2 does not have the needed public key to decrypt the identification cert.ficate. the 
registration transaction terminates in an error, step 1618. j„„ m »=rt otanieos Ratios- 

Assuming that repository-2 has the proper public key the identrticat.cn certificate '^ecnypted^ te p i 60 5 g Repos 
itorv 2 saves the encrypted registration identifier, step 1606, and extracts the reposrtory .dentifier. step 1607 The 
SaLTrepoittory identifier is checked against a "hotlisf of compromised document repositories, * ^OSJn the 
SrentW preferred embodiment, each repository will contain "hotlists- of comprom.sed reposrtones. If the repos ory 
* on toe CtHheTegistration transaction terminates in an error per step 1618. Repository 
h rhoJL Sen heir certificates expire, so that the list does not need to grow without bound. A.so, by keeping a short 
rc?^ rcertificates that it has previously received, a repository can avoid the work of actually going through the 
2 T^fSX^Z^^ by a master reposrtory. A minor variation on the approach to improve efficacy 
wtuW have the reposrtones fire'exchange lists of names of hotlist certificates, ultimately exchanging only those lists 
mtuhev had not previously received. The "hotlists" are maintained and distributed by Master reposrtones. 

N^SatSherThan terminating in error, the transaction could request that another reg.stration message , be sent 
based S ridelication certificate 9 created by another master repository. This may be repeated until a satisfactory 

repoS 3 ^needl to vacate thtf .he repository on the other end is really repository^ This istorme d pertomnance 
esS and is performed in order to avoid invalid access to the repository v.a a counterfert repos tony flaying a re 
c oSa of a prior se^on initiation between repository-1 and repository-2. Performance testing is mitiated by reposrtory- 
2 oenere ^^ing'a pertSmance message, step 1609. The performance message consists of a nonce, the names of the 
fesoeSe repertories, the time and the registration identifier received from reposrtory-1. A nonce is a generated 
ZsaTbSJSSi. random and variable information (e.g. the time or the temperature.) The nonce .8 used o 

can actually exhibit correct encrypting of a message using the pnvate keys it Cairns to 

JthTco?npae^^ 

2 then compares rne registration transaction has successfully completed 

tefm Atthi ^Z£&™£^ -s not terminated, the ^^^^^.^^^ 
; session keys to be used in all communications during the session and synchronize their clocks. Fl ^ 1 ™ u *"2£ 
the sessSn information exchange and clock synchronization steps (again from the perspec ive oT ^"H^ 
errina to Rqure 17 repository-1 creates a session key pair, step 1701. A first key is kept pnvate and is used by 
r^i^r^/rnsJges. The second key is a public key used by reposrtory-2 to decrypt messages. The 
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second key is encrypted using the public key of repository-2, step 1702 and is sent to repository-2. step 1703. Upon 
receipt repository-2 decrypts the second key, step 1704. The second key is used to decrypt messages in subsequent 
communications When each repository has completed this step, they are both convinced that the other repository is 
bona fide and that they are communicating with the original. Each repository has given the other a key to be used in 
s decrypting further communications during the session. Since that key is itself transmitted in the public key of the re- 
ceiving repository only it will be able to decrypt the key which is used to decrypt subsequent messages. 

After the session information is exchanged, the repositories must synchronize their clocks. Clock synchronization 
is used by the repositories to establish an agreed upon time base for the financial records of their mutual transactions. 
Referring back to Figure 1 7 repository-2 initiates clock synchronization by generating a time stamp exchange message, 
10 step 1705, and transmits it to repository-1 , step 1 706. Upon receipt, repository-1 generates its own time stamp mes- 
sage step 1707 and transmits it back to repository-2, step 1708. Repository-2 notes the current time, step 1709 and 
stores the time receivedfrom repository-1 , step 1 710. The current time iscomparedto thetime received from repository- 
1 step 1711 The difference is then checked to see if it exceeds a predetermined tolerance (e.g. one minute), step 
171 2 If it does repository-2 terminates the transaction as this may indicate tampering with the repository, step 1713. 
is If not repository-2 computes an ad|usted time delta, step 1714. The adjusted time delta is the difference between the 
clock time of repository-2 anc the average of the times from repository-1 and repository-2. 

To achieve greater accuracy repos.tory-2 can request the time again up to a fixed number of times (e.g. five times), 
repeat the clock synchronization steps and average the results. 

A second session initiation transaction is a Login transaction. The Login transaction is used to check the authenticity 
20 of a user requesting a transaction A Login transaction is particularly prudent for the authorization of financial transac- 
tions that will be charged to a c.edit server. The Login transaction involves an interaction between the user at a user 
interface and the credit server associated with a repository. The information exchanged here is a login string supplied 
by the repository/credit server to identify itself to the user, and a Personal Identification Number (PIN) provided by the 
user to identify himself to the credit server. In the event thatthe user is accessing a credit server on a repository different 
2S from the one on which the user interface resides exchange of the information would be encrypted using the public and 
private keys of the respective repositories. 

Billing Transactions 

30 Billing Transactions are concerned wilh monetary transactions with a credit server. Billing Transactions are carried 

out when all other conditions are satisfied and a usage fee is required for granting the request. For the most part, billing 
transactions are well understood in the state of the art. These transactions are between a repository and a credit server, 
or between a credit server and a billing clearinghouse. Briefly, the required transactions include the following: 

Registration and LOG IN transactions by which the repository and user establish their bona fides to a credit server. 
These transactions would be entirely internal in cases where the repository and credit server are implemented as 
a single system. 

Registration and LOGIN transactions, by which a credit server establishes its bona fides toa billing clearinghouse. 
An Assign-fee transaction to assign a charge. The information in this transaction would include a transaction iden- 
tifier the identities of the repositories in the transaction, and a list of charges from the parts of the digital work. If 
there has been any unusual event in the transaction such as an interruption of communications, that information 

is included as well. • 
. A Begin-charges transaction to assign a charge. This transaction is much the same as an assign-fee transaction 
except that it is used tor metered use. It includes the same information as the assign-fee transaction as well as 
4S the usage fee information. The credit-server is then responsible for running a clock. 

. An End-charges transaction to end a charge for metered use. (In a variation on this approach, the repositories 

would exchange periodic charge information for each block of time.) 
. A report-charges transaction between a personal credit server and a billing clearinghouse. This transaction is 
invoked at least once per billing period. It is used to pass along information about charges. On debrt and credit 
so cards, this transaction would also be used to update balance information and credit limits as needed. 

All billing transactions are given a transaction ID and are reported to the credit severs by both the server and the 
client. This reduces possible loss of billing information if one of the parties to a transaction loses a banking card and 
provides a check against tampering with the system. 
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Usage Transactions 

After the session initiation transactions have been completed, the usage request may then be processed. To sim- 
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requested right is not in the set of remaining rights, the server terminates the transaction, step 1805. 

If Loan is not a usage right for the digital work or il all copies have not been loaned out or the requested right is in ■ 
the set of remaining rights, fee conditions for the right are then checked, step 1815. This will initiate various financial 
transactions between the repository and associated credit server. Further, any metering of usage of a digital work will 
5 commence. If any financial transaction fails, the transactbn terminates per step 1805. 

It should be noted that the order in which the conditions are checked need not follow the order of steps 1 806-1 81 5. 

At this point, right specific steps are now performed and are represented here as step 1816. The right specific 
steps are described in greater detail below. 

The common closing transaction steps are now performed. Each of the closing transaction steps are performed 
io by the server after a successful completion of a transaction. Referring back to Figure 18, the copies in use value for 
the requested right is decremented by the number of copies involved in the transaction, step 1817. Next, if the right 
had a metered usage fee specification, the server subtracts the elapsed time from the Remaining-Use-Time associated 
with the right for every part involved in the transaction, step 1818. Finally, if there are fee specifications associated 
with the right, the server initiates End-Charge financial transaction to confirm billing, step 1819. 
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Transmission Protocol 



An important area to consider is the transmission of the digital work from the server to the requester. The trans- 
mission protocol described herein refers to events occurring after a valid session has been created. The transmission 
20 protocol must handle the case of disruption in the communications between the repositories. It is assumed that inter- 
ference such as injecting noise on the communication channel can be detected by the integrity checks (e.g., parity, 
checksum, etc.) that are built into the transport protocol and are not discussed in detail herein. 

The underlying goal in the transmission protocol is to preclude certain failure modes, such as malicious or accidental 
interference on the communications channel. Suppose, for example, that a user pulls a card with the credit server at 
25 a specific time near the end of a transaction. There should not be a vulnerable time at which "pulling the card" causes 
the repositories to fail to correctly account for the number of copies of the work that have been created. Restated, there 
should be no time at which a party can break a connection as a means to avoid payment after using a digital work. 

If a transaction is interrupted (and fails), both repositories restore the digital works and accounts to their state prior 
to the failure, modulo records of the failure itself. 
30 Figure 19 is a state diagram showing steps in the process of transmitting information during a transaction. Each 

box represents a state of a repository in either the server mode (above the central dotted line 1 901 ) or in the requester 
mode (below the dotted line 1 901 ). Solid arrows stand for transitions between states. Dashed arrows stand for message 
communications between the repositories. A dashed message arrow pointing to a solid transition arrow is interpreted 
as meaning that the transition takes place when the message is received. Unlabeled transition arrows take place 
35 unconditionally. Other labels on state transition arrows describe conditions that trigger the transition. 

Referring now to Figure 19, the server is initially in a state 1902 where a new transaction is initiated via start 
message 1903. This message includes transaction information including a transaction identifier and a count of the 
blocks of data to be transferred. The requester, initially in a wait state 1904 then enters a data wait state 1905. 

The server enters a data transmit state 1906 and transmits a block of data 1907 and then enters a wait for ac- 
40 knowledgement state 1 908. As the data is received, the requester enters a data receive state 1 909 and when the data 
blocks are completely received it enters an acknowledgement state 1 91 0 and transmits an Acknowledgement message 
1911 to the server. 

If there are more blocks to send, the server waits until receiving an Acknowledgement message from the requester. 
When an Acknowledgement message is received it sends the next block to the requester and again waits for acknowl- 
45 edgement. The requester also repeats the same cycle of states. 

If the server detects a communications failure before sending the last block, it enters a cancellation state 1912 
wherein the transaction is cancelled. Similarly, if the requester detects a communications failure before receiving the 
last block it enters a cancellation state 1913. 

If there are no more blocks to send, the server commits to the transaction and warts for the final Acknowledgement 
so in state 1914. If there is a communications failure before the server receives the final Acknowledgement message, it 
still commits to the transaction but includes a report about the event to its credit server in state 1915. This report serves 
two purposes. It will help legitimize any claims by a user of having been billed for receiving digital works that were not 
completely received. Also it helps to identify repositories and communications lines that have suspicious patterns of 
use and interruption. The server then enters its completion state 1916. 
55 On the requester side, when there are no more blocks to receive, the requester commits to the transaction in state 

1917. If the requester detects a communications failure at this state, it reports the failure to its credit server in state 

1918, but still commits to the transaction. When it has committed, it sends an acknowledgement message to the server. 
The server then enters its completion state 1919. 
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The key property is that both the server and the requester cancel a transaction if it is interrupted before all of the 
data blocks are delivered, and commits to it if all of the data blocks have been delivered. 

There is a possibility that the server will have sent all of the data blocks (and committed) but the requester will not 
have received all of them and will cancel the transaction. In this case, both repositories will presumably detect a com- 
munications failure and report it to their credit server. This case will probably be rare since it depends on very precise 
timing of the communications failure. The only consequence will be that the user at the requester repository may want 
to request a refund from the credit services -- and the case for that refund will be documented by reports by both 

reposrtories^ ^ ^ ^ ^ ^ ^ transferred digital work until receiving the final acknowl- 

edgement from the requester But it also should not use the file. A well known way to deal with this situation is called 
"two-phase commit* or 2PC 

Two-phase commit works as follows. The first phase works the same as the method described above. The server 
sends all of the data to the requester. Both repositories mark the transaction (and appropriate files) as uncommitted. 
The server sends a ready-lo-commit message to the requester. The requester sends back an acknowledgement. The 
server then commits and sends the requester a commit message. When the requester receives the commit message, 

11 ^mere^ acommun.cat.on failure or other crash, the requester must check back with the server to determine the 
status of the transact.cn The server has the last word on this. The requester may have received all of the data, but if 
it did not get the final message it has not committed. The server can go ahead and delete files (except for transaction 
records) once it commits s.nce the files are known to have been fully transmitted before starting the 2PC cycle. 

There are variations known .n the art which can be used to achieve the same effect. For example, the server could 
use an additional level ot encrypHon when transmitting a work to a client. Only after the client sends a message ac- 
knowledging receipt does it send the key. The client then agrees to pay for the digital work. The point of this variation 
is that it provides a clear audit trail that the client received the work. For trusted systems, however, this variation adds 
2S a level of encryption for no real gain in accountability. 

The transaction for specific usage rights are now discussed. 

The Copy Transaction 
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A Copy transaction is a request to make one or more independent copies of the work with the same or lesser 
usage rights. Copy differs from the extraction right discussed later in that it refers to entire digital works or entire folders 
containing digital works. A copy operation cannot be used to remove a portion of a digital work. 

as . The requester sends the server a message to initiate the Copy Transaction. This message indicates the work to 
be copied the version of the copy right to be used for the transaction, the destination address information (location 
in a folder) for placing the work, the file data for the work (including its size), and the number of copies requested. 
• The repositories perform the common opening transaction steps. 

. The server transmits the requested contents and data to the client according to the transmission protocol. If a 
40 Next-Set-Of-Rights has been provided in the version of the right, those rights are transmitted as the rights for the 

work. Otherwise, the rights of the original are transmitted. In any event, the Copy-Count field for the copy of the 
diqital work being sent right is set to the number-of-copies requested. 
. The requester records the work contents, data, and usage rights and stores the work. It records the date and time 
that the copy was made in the properties of the digital work. 
46 • -The repositories perform the common closing transaction steps. 

The Transfer Transaction 

A Transfer transaction is a request to move copies of the work with the same or lesser usage rights to another 
so repository. In contrast with a copy transaction, this results in removing the work copies from the server. 

. The requester sends the server a message to initiate the Transfer Transaction. This message indicates the work 
to be transferred, the version of the transfer right to be used in the transaction, the destination address information 
for placing the work, the file data for the work, and the number of copies involved. 
ss • The repositories perform the common opening transaction steps. 

. The server transmits the requested contents and data to the requester according to the transmission protocol. If 
a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the work. Otherwise, the 
rights of the original are transmitted. In either case, the Copy-Count field for the transmitted rights are set to the 
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number-of -copies requested. 

• The requester records the work contents, data, and usage rights and stores the work. 

• The server decrements its copy count by the number of copies involved in the transaction. 

• The repositories perform the common closing transaction steps. 

5 • If the number of copies remaining in the server is now zero, it erases the digital work from its memory. 

The Loan Transaction 

A loan transaction is a mechanism for loaning copies of a digital work. The maximum duration of the loan is de- 
10 termmed by an internal parameter of the digital work. Works are automatically returned after a predetermined time 
period 

. The requester sends the server a message to initiate the Transfer Transaction. This message indicates the work 
to be loaned the version of the loan right to be used in the transaction, the destination address information for 
75 pucne the work the number of copies involved, the file data for the work, and the period of the loan. 

. The server checks the validity of the requested loan period, and ends with an error if the period is not valid. Loans 
lor h toned copy cannot extend beyond the period of the original loan to the server. 

• The repositories perform the common opening transaction steps. 

• The server transmits the requested contents and data to the requester. If a Next-Set-Of-Rights has been provided, 
20 tnose rights are transmitted as the rights for the work. Otherwise, the rights ot the original are transmitted, as 

modified to reflect the loan period. 

• The requester records the digital work contents, data, usage rights, and loan period and stores the work. 

• The server updates the usage rights information in the digital work to reflect the number of copies loaned out. 

• The repositories perform the common closing transaction steps. 

25 . The server updates the usage rights data for the digital work. This may preclude use of the work until it is returned 
from the loan The user on the requester platform can now use the transferred copies of the digital work. A user 
accessing the original repository cannot use the digital work , unless there are copies remaining. What happens 
next depends on the order of events in time. 

30 case 1 if the lime of the loan period is not yet exhausted and the requester sends the repository a Return 

message. 

• The return message includes the requester identification, and the transaction ID. 

• The server decrements the copies-in-use field by the number of copies that were returned. (If the number 
ol digital works returned is greater than the number actually borrowed, this is treated as an error.) This 
step may now make the work available at the server for other users. 

• The requester deactivates its copies and removes the contents from its memory. 

Case 2. If the time of the loan period is exhausted and the requester has not yet sent a Return messages 

40 

• The server decrements the copies-in-use field by the number digital works that were borrowed. 

• The requester automatically deactivates its copies of the digital work. It terminates all current uses and 
erases the digital work copies from memory. One question is why a requester would ever return a work 
earlier than the period of the loan, since it would be returned automatically anyway. One reason for early 

45 return is that there may be a metered fee which determines the cost of the loan. Returning early may 

reduce that fee. 

The Play Transaction 

so A play transaction is a request to use the contents of a work. Typically, to "play" a work is to send the digital work 

through some kind of transducer, such as a speaker or a display device. The request implies the intention that the 
contents will not be communicated digitally to any other system. For example, they will not be sent to a printer, recorded 
on any digital medium, retained after the transaction or sent to another repository. 

This term "play" is natural for examples like playing music, playing a movie, or playing a video game. The general 

55 form of play means that a "player" is used to use the digital work. However, the term play covers all media and kinds 
of recordings. Thus one would "play" a digital work, meaning, to render it for reading, or play a computer program, 
meaning to execute it. For a digital ticket the player would be a digital ticket agent. 
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. The requester sends the server a message to initiate the play transaction. This message indicates the work to be 
played, the version of the play right to be used in the transaction, the identity of the player being used, and the file 

. Th?s?rve^cks the validity of the player identification and the compatibility of the player identification with the 

5 player specification in the right. It ends with an error if these are not satisfactory. 

• The repositories perform the common opening transactbn steps. 

. The server and requester read and write the blocks of data as requested by the player according to the transmission 

protocol The requester plays the work contents, using the player. 

. When the player is finished, the player and the requester remove the contents from their memory. 

10 • The repositories perform the common closing transaction steps. 

The Print Transaction 

A Print transaction is a request to obtain the contents of a work for the purpose of rendering them on a "printer." 
We use the term -printer" to include the common case of writing with ink on paper. However, the key aspect of printing 
in our use of the term is that it makes a copy of the digital work in a place outside of the protection ol usage rights. As 
with all riqhts, this may require particular authorization certificates. 

Once a digital work is printed, the publisher and user are bound by whatever copyright laws are in effect. However, 
printing moves the contents outside the control of repositories. For example, absent any other enforcement mecha- 
nisms once a digital work is printed on paper, it can be copied on ordinary photocopying machines without intervention 
bv a repository to collect usage fees. If the printer to a digital disk is permitted, then that digital copy .s ou side of the 
control of usage rights. Both the creator and the user know this, although the creator does not necessarily give tacit 
consent to such copying, which may violate copyright laws. 

. The requester sends the server a message to initiate a Print transaction. This message indicates the work to be 
played, the identity of the printer being used, the file data for the work, and the number of cop.es in the request. 
. The server checks the validity of the printer identification and Ihe compatibility of the printer .dentrf.cation with the 
printer specification in the right. It ends with an error if these are not satisfactory. 

• The repositories perform the common opening transactbn steps. 

30 • The server transmits blocks of data according to the transmission protocol. 

• The requester prints the work contents, using the printer. 

. When the printer is finished, the printer and the requester remove the contents from their memory. 

• The repositories perform the common closing transaction steps. 

35 The Backup Transaction 

A Backup transaction is a request to make a backup copy of a digital work, as a protection against media failuro 
In the context of repositories, secure backup copies differ from other copies in three ways: (1) they are made unde 
the control of a Backup transaction rather than a Copy transaction, (2) they do not count as regular copies, and (3) 
40 thev are not usable as regular copies. Generally, backup copies are encrypted. 

Although backup copies may be transferred or copied, depending on their assigned rights, the only way to make 
them useful for playing, printing or embedding is to restore them. 

The output of a Backup operation is both an encrypted data file that contains the contents and descr.pt.on of a 
work and a restoration file with an encryption key for restoring the encrypted contents. In many cases, the encrypted 
data file would have rights for "printing" it to a disk outside of the protection system, relying just on rts encjypton for 
security Such files could be stored anywhere that was physically safe and convenient. The restoration ft e would I be 
held in the repository This file is necessary for the restoration of a backup copy. It may have rights tor transfer between 
repositories. 

• The requester sends the server a message to initiate a backup transaction. This message indicates the work to 
be backed up, the version of the backup right to be used in the transaction, the destination address mformat.on 
for placing the backup copy, the file data for the work. 

• The repositories perform the common opening transaction steps. 

. The server transmits the requested contents and data to the requester. If a Next-SetOf-Rights has been provided, 
those rights are transmitted as the rights for the work. Otherwise, a set of default rights for backup files of the 
oriqinal are transmitted by the server. 
. The requester records the work contents, data, and usage rights. It then creates a one-time key and encrypts the 
contents file. It saves the key information in a restoration file. 
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• The repositories perform the common closing transaction steps. 

In some cases, it is convenient to be able to archive the large, encrypted contents file to secure offline storage, 
such as a magneto-optical storage system or magnetic tape. This creation of a non-repository archive file is as secure, 
as the encryption process. Such non-repository archive storage is considered a form of "printing 0 and is controlled by 
a print right with a specified "archive-printer 0 An archive-printer device is programmed to save the encrypted contents 
file (but not the description file) offline in such a way that it can be retrieved. 

The Restore Transaction 

A Restore transaction is a request to convert an encrypted backup copy of a digital work into a usable copy. A 
restore operation is intended to be used to compensate for catastrophic media failure. Like all usage rights, restoration 
rights can include fees and access tests including authorization checks. 

• The requester sends the server a message to initiate a Restore transaction. This message indicates the work to 
be restored, the version of the restore right for the transaction, the destination address information for placing the 
work, and the file data for the work. 

. The server verifies that the contents file is available (i.e. a digital work corresponding to the request has been 
backed-up.) If it is not, it ends the transaction with an error. 

• The repositories perform the common opening transactbn steps. 

• The server retrieves the key from the restoration file. It decrypts the work contents, data, and usage rights. 

• The server transmits the requested contents and data to the requester according to the transmission protocol. If 
a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the work. Otherwise, a set 
of default rights for backup files of the original are transmitted by the server. 

• The requester stores the digital work. 

• The repositories perform the common closing transaction steps. 



The Delete Transaction 

30 A Delete transaction deletes a digital work or a number of copies of a digital work from a repository. Practically 

digital works would have delete rights. 

• The requester sends the server a message to initiate a delete transaction. This message indicates the work to 
deleted , the version of the delete right for the transaction. 

35 • The repositories perform the common opening transactbn steps. 

• The server deletes the file, erasing it from the file system. 

• The repositories perform the common closing transaction steps. 



The Directory Transaction 

40 

A Directory transaction is a request for information about folders, digital works, and their parts. This amounts to 
roughly the same idea as protection codes in a conventional file system like TENEX, except that it is generalized to 
the full power of the access specifications of the usage rights language. 

The Directory transaction has the important role of passing along descriptions of the rights and fees associated 
45 with a digital work. When a user wants to exercise a right, the user interface of his repository implicitly makes a directory 
request to determine the versions of the right that are available. Typically these are presented to the user - such as 
with different choices of billing for exercising a right. Thus, many directory transactions are invisible to the user and 
are exercised as part of the normal process of exercising all rights. 

so • The requester sends the server a message to initiate a Directory transaction. This message indicates the file or 
folder that is the root of the directory request and the version of the directory right used for the transaction. 

• The server verifies that the information is accessible to the requester. In particular, it does not return the names 
of any files that have a HIDE-NAME status in their directory specifications, and it does not return the parts of any 
folders or files that have HIDE-PARTS in their specification. If the information is not accessible, the server ends 

55 the transaction with an error. 

• The repositories perform the common opening transactbn steps. 

• The server sends the requested data to the requester according to the transmission protocol. 

• The requester records the data. 
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♦ The repositories perform the common closing transaction steps. 
The Folder Transaction 

5 A Folder transaction is a request to create or rename a folder, or to move a work between folders. Tog^wwtth 

DreWri^ Folder rights contro. the degree to which organization of a repository can be accessed or modified 
from another repository. 

. The requester sends the server a message to initiate a Folder transaction. This message indicates the folder that 
, thcloot o. the folder request, the version of the folder right for the transacts, an dWaTh. 
operation can be one of create, rename, and move file. The data are the specrf.cat.ons requ.red for the operate, 
such as a specification of a folder or digital work and a name. 
. The repos.tor.es perform the common opening transaction steps. wrtrk batween 

. The server performs the requested operation - creating a folder, renam.ng a folder, or moving a work between 

is folders 

• The rcpos.toi.es perform the common closing transaction steps. 

The Extract Transaction 

A extract transacts « a request to copy a part of a digital work and to create a new work containing it. The 
extract^nSe aX^oZs from copying in that it can be used to separate a part of a digital work f rom , dttocta .or 
STS^Sion- restrictions o'r fees on it. The extraction operation differs from the «* opjj-Ujnjn that rf 
does not change the contents of a work, only its embedding in d-blocks. Extract.cn creates a new d.grtal work. 

. The requestor sends the server a message to initiate an Extract transaction. This message indteates the .part of 
the work to be extracted, the version of the extract right to be used in the transaction, the dest.nat.on address 
Info^ for ptaang the part as a new work, the file data for the work, and the number of cop.es .nvotved. 

• The repositories perform the common opening transaction steps. 

. The server transits the requested contents and data to the requester to J^*"^ gjS." 

a Next-Set-Ot-R.ghts has been provided, those rights are transmrtted as the rights for the new 
the n gh,sof,heong.na.aretransmmed.TheCopy-Countfieldforthisrigh^ 
. The requester records the contents, data, and usage rights and stores the work. It records the date and time that 
new work was made in the properties of the work. 

• The repositories perform the common closing transaction steps. 

The Embed Transaction 

An embed transaction is a request to make a digital work become a part of another digital work or to add a shell 
d-block to enable the adding of fees by a distributor of the work. 

. The reouester sends the server a message to initiate an Embed transaction. This message indicates the work to 
le embedded I, the ve^ oTthe embed'right to be used in the transaction, the destination address ,nformat.on 
fnr nlacina the Dart as a a work, the file data for the work, and the number of copies involved. 
. The ftS £ checks the contro. specifications for a., of the rights in the part and the destination. If they are mcom- 
4S patible. the server ends the transaction with an error. 

• The repositories perform the common opening transaction steps. „ r „.«or.i if 
. The server transmits the requested contents and data to the requester accord.ng to the transm.ss.on protocol If 

I Next-Se -ot -Rights has been provided, those rights are transmitted as the rights for the new work. Otherw se, 
The^ts^ 

. The requester records the contents, data, and usage rights and embeds the work in the destination file. 

• The repositories perform the common closing transaction steps. 

The Edit Transaction 

An Edit transaction is a request to make a new digital work by copying, selecting and modifying P°*tons °f an 
exist^g d^itaTwlrk This operation can actually change the contents of a digital work. The kinds of 
pe mrfted depend on the process being used Like the extraction operation, edit operates on ^^^^ 
E contrast wrfh the extract operation, edit does not affect the rights or location of the work. It only changes the contents. 
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The kinds of changes permitted are determined by the type specification of the processor specified in the rights. In the 
currently preferred embodiment, an edit transaction changes the work itself and does not make a new work. However, 
it would be a reasonable variation to cause a new copy of the work to be made. 

5 • The requester sends the server a message to initiate an Edit transaction. This message indicates the work to be 
edited, the version of the edit right to be used in the transaction, the file data for the work (including its size), the 
process-ID for the process, and the number of copies involved. 

• The server checks the compatibility of the process-ID to be used by the requester against any process-ID speci- 
fication in the right. If they are incompatible, it ends the transaction with an error. 

10 • The repositories perform the common opening transaction steps. 

• The requester uses the process to change the contents of the digital work as desired. (For example, it can select 
and duplicate parts of it; combine it with other information; or compute functions based on the information. This 
can amount to editing text, music, or pictures or taking whatever other steps are useful in creating a derivative work. ) 

• The repositories perform the common closing transaction steps. 

15 

The edit transaction is used to cover a wide range of kinds of works. The category describes a process that takes 
as its input any portion of a digital work and then modifies the input in some way. For example, for text, a process for 
editing the text would require edit rights. A process for "summarizing" or counting words in the text would also be 
considered editing. For a music file, processing could involve changing the pitch or tempo, or adding reverberations, 

20 or any other audio effect. For digital video works, anything which alters the image would require edit rights. Examples 
would be colorizing, scaling, extracting still photos, selecting and combining frames into story boards, sharpening with 
signal processing, and so on. 

Some creators may want to protect the authenticity of their works by limiting the kinds of processes that can be 
performed on them. If there are no edit rights, then no processing is allowed at all. A processor identifier can be included 

25 to specify what kind of process is allowed. If no process identifier is specified, then arbitrary processors can be used. 
For an example of a specific process, a photographer may want to allow use of his photograph but may not want it to 
be colorized. A musician may want to allow extraction of portions of his work but not changing of the tonality. 



Authorization Transactions 

30 

There are many ways that authorization transactions can be defined. In the following, our preferred way is to simply 
define them in terms of other transactions that we already need for repositories. Thus, it is convenient sometimes to 
speak of "authorization transactions, " but they are actually made up of other transactions that repositories already have. 
A usage right can specify an authorization-ID, which identifies an authorization object (a digital work in a file of a 
35 standard format) that the repository must have and which it must process. The authorization is given to the generic 
authorization (or ticket) server of the repository which begins to interpret the authorization. 

As described earlier, the authorization contains a server identifier, which may just be the generic authorization 
server or it may be another server. When a remote authorization server is required, it must contain a digital address. 
It may also contain a digital certificate. 
40 if a remote authorization server is required, then the authorization process first performs the following steps: 

• The generic authorization server attempts to set up the communications channel. (If the channel cannot be set 
up, then authorization fails with an error.) 

• When the channel is set up, it performs a registration process with the remote repository. (If registration fails, then 
45 the authorization fails with an error.) 

• When registration is complete, the generic authorization server invokes a "Play" transaction with the remote re- 
pository, supplying the authorization document as the digital work to be played, and the remote authorization server 
(a program) as the "player." (If the player cannot be found or has some other error, then the authorization fails with 
an error.) 

so • The authorization server then "plays" the authorization. This involves decrypting it using either the public key of 
the master repository that issued the certificate or the session key from the repository that transmitted it. The 
authorization server then performs various tests. These tests vary according to the authorization server. They 
include such steps as checking issue and validity dates of the authorization and checking any hot-lists of known 
invalid authorizations. The authorization server may require carrying out any other transactions on the repository 

55 as well, such as checking directories, getting some person to supply a password, or playing some other digital 

work. It may also invoke some special process for checking information about locations or recent events. The 
"script" for such steps is contained within the authorization server. 

• If all of the required steps are completed satisfactorily, the authorization server completes the transaction normally, 
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signaling that authorization is granted. 
The Install Transaction 

s An Install transaction is a request to install a digital work as runnable software on a repository. In a typical case, 

the requester repository is a rendering repository and the software would be a new kind or new version of a player. 
Also in a typical case, the software would be copied to file system of the requester repository before it is installed. 

. The requester sends the server an Install message. This message indicates the work to be installed, the version 
10 of the Install right being invoked, and the file data for the work (including its size). 

• The repositories perform the common opening transaction steps. 

. The requester extracts a copy of the digital certificate lor the software. If the certificate cannot be found or the 

master repository for the certificate is not known to the requester, the transaction ends with an error. 
. The requester decrypts the digital certificate using the public key of the master repository, recording the identity 
15 of the supplier and creator, a key for decrypting the software, the compatibility information, and a tamper^hecking 

code. (This step certifies the software.) = 
. The requester decrypts the software using the key from the certificate and computes a check code on it using a 
1-way hash function. If the check-code does not match the tamper-checking code from the certificate, the instal- 
lation transaction ends with an error. (This step assures that the contents of the software, including the various 
20 scripts, have not been tampered with.) 

. The requester retrieves the instructions in the compatibility^hecking script and follows them. If the software is not 
compatible with the repository, the installation transaction ends with an error. (This step checks platform compat- 

. Sequester retrieves the instructions in the installation script and follows them. If there is an error in this process 
2S (such as insufficient resources), then the transaction ends with an error. Note that the installation process puts the 

runnable software in a place in the repository where it is no longer accessible as a work for exercising any usage 
rights other than the execution of the software as part o1 repository operations in carrying out other transactions. 
• The repositories perform the common closing transaction steps. 

30 The Uninstall Transaction 

An Uninstall transaction is a request to remove software from a repository. Since uncontrolled or incorrect removal 
of software from a repository could compromise its behavioral integrity, this step is controlled. 

The requester sends the server an Uninstall message. This message indicates the work to be uninstaller the 
version of the Uninstall right being invoked, and the file data for the work (including its size). 
The repositories perform the common opening transaction steps. 

The requester extracts a copy of the digital certificate lor the software. If the certificate cannot be found or the 
master repository for the certificate is not known to the requester, the transaction ends with an error. 
The requester checks whether the software is installed. If the software is not installed, the transaction ends with 

TheTequester decrypts the digital certificate using the public key of the master repository, recording the identity 
of the supplier and creator, a key for decrypting the software, the compatibility information, and a tamper-checking 
code (This step authenticates the certification of the software, including the script for uninstallmg it.) 
The requester decrypts the software using the key from the certificate and computes a check code on it using a 
1-way hash function. If the check-code does not match the tamper^hecking code from the certificate, the instal- 
lation transaction ends with an error. (This step assures that the contents of the software, including the vanous 
scripts, have not been tampered with.) . 
. The requester retrieves the instructions in the uninstallation script and follows them. If there is an error in this 
so process (such as insufficient resources), then the transaction ends with an error. 

• The repositories perform the common closing transaction steps. 
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Claims 

1 . A system for controlling the distribution and use of digital works comprising: 

means for attaching one or more usage rights to a digital work, each of said one or more usage rights specifying 
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a particular instance of how said digital work may be used or distributed, each of said usage rights being 
capable of specifying a digital ticket, the possession of said digital ticket being a condition on the exercise of 
a right specifying said digital ticket; 

a plurality of repositories for storing and exchanging digital works, each of said plurality of repositories com- 
prising: 

storage means for storing digital works, their attached usage rights, and digital tickets; 
transaction processing means having a requester mode of operation for requesting access to a digital work, 
said request specifying a usage right, and a server mode of operation for processing requests to access said 
requested digital work based on said usage right specified in said request, the usage rights attached to said 
digital work, and digital tickets associated with said usage rights; 

a generic ticket agent for punching digital tickets to indicate that an associated usage right has been exercised; 
and 

a coupling means for coupling to another of said plurality of repositories across a communications medium. 

The system as recited in Claim 1 wherein a usage right may specify a special ticket agent for punching a specified 
digital ticket and said system is further comprised of one or more authorization repositories containing special 
ticket agents for punching digital tickets. 

The system as recited in Claim 1 wherein said digital ticket is comprised of a first timestamp part for indicating a 
time when said digital ticket was copied and a second timestamp part for indicating a time when said digital ticket 
was punched. 

The system as recited in Claim 3 wherein said generic ticket agent is further comprised of a means for determining 
if a digital ticket is valid and timestamping means for timestamping digital tickets when they are punched. 

A method for controlling access to digital works in a computer controlled system for the distribution of digital works, 
comprising the steps of: 

a) creating a digital work and a digital ticket for said digital work; 

b) attaching a usage right to said digital work, said usage right specifying said digital ticket; 

c) storing said digital work in a first repository; 

d) storing said digital ticket in a second repository; 

e) a third repository acquiring said digital ticket from said second repository; 

f) said third repository transmitting a request to access said digital work to said first repository, said request 
specifying said usage right; 

g) said first repository determining if said third repository has said digital ticket; 

h) said third repository presenting said digital ticket to said first repository; 

i) said first repository transmitting said digital work to said third repository; and 
j) said first repository punching said digital ticket. 

The method as recited in Claim 5 wherein said step of a third repository acquiring said digital ticket from said 
second repository is further comprised of the step of said third repository copying said digital ticketf rom said second 
repository for a fee. 

The method as recited in Claim 6 wherein said digital ticket is comprised of a first timestamp part for storing a time 
when said digital ticket was copied and a second timestamp part for storing a timestamp when said digital ticket 
was punched and said step of copying said digital ticket from said second repository for a fee is further comprised 
of the step of said second repository marking said first timestamp part of said digital ticket with a copy timestamp 
indicating the time and date when the copy of said digital ticket was made. 

A method for controlling the number of times that a usage right attached to a digital work may be exercised in a 
computer controlled system for the distribution of digital works, said method comprising the steps of: 

a) creating a digital work; 

b) defining a usage right for said digital work, said usage right specifying a digital ticket indicating a predeter- 
mined number of times that said usage right may be exercised; 

c) creating said digital ticket with an indicator of said predetermined number; 

d) storing said digital work, said usage right and said digital ticket in a first repository; 
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e) a second repository transmitting a request to access said digital work to said first repository, said request 
specifying said usage right; 

f) said first repository determining if said digital ticket for said usage right indicates that said usage right has 
been exercised said predetermined number of times; 

g) if said digital ticket indicates that said usage right has been exercised said predetermined number of times, 
said first repository denying access to said digital work; 

h) if said digital ticket indicates that said usage right has not been exercised said predetermined number of 
times, said first repository granting access to said digital work; and 

i) said first repository punching said digital ticket to indicate an instance of exercising said usage right. 

9. A method for controlling the access to digital works in a computer controlled system for the distribution of digital 
works, said method comprising the steps of: 

a) creating a digital work and a digital ticket; 
is b) defining a usage right for said digital work, said usage right specifying said digital ticket and a special ticket 

agent for punching said digital ticket; 

c) storing said digital work in a first repository; 

d) distributing said digital ticket to a second repository; 

e) said second repository transmitting a request to access said digital work to said first repository, said request 
20 specifying said usage right; 

f ) said first repository determining if said second repository has said digital ticket; 

g) said second repository presenting said digital ticket to said first repository; 

h) said first repository presenting said digital ticket to said special ticket agent; 

i) said special ticket agent determining if said digital ticket is valid; 

25 j) if said digital ticket is invalid, said special ticket agent causing said request to access to be denied; 

k) if said digital ticket is valid, said special ticket agent punching said digital ticket; and 
I) said first repository granting access to said digital work by said second repository. 

10. A method for distribution of upgrades to digital works in a computer controlled system for the distribution of digital 
30 works, said method comprising the steps of: 

a) creating a digital ticket, said digital ticket permitting copying of an upgrade digital work; 

b) distributing said digital ticket and a corresponding digital work to a first repository for a fee; 

c) creating said upgrade digital work, said upgrade digital work having a copying right for permitting copying 
35 of said upgrade digital work to possessors of said digital ticket; 

d) storing said upgrade digital work in a second repository; 

e) said first repository transmitting a request to copy said digital work to said second repository; 

f) said second repository determining if said first repository has said digital ticket; 

g) said first repository presenting said digital ticket to said second repository; 
40 i) said second repository determining if said digital ticket is valid; 

j) if said digital ticket is invalid, said second repository causing said request to copy to be denied; 
k) if said digital ticket is valid, said second repository punching said digital ticket; and 
I) said second repository transmitting said upgrade digital work to said first repository. 
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1501 —Digital Work Rights:= (Rights*) 

1502 — Right : = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec } 
{Access-Spec} {Fee-Spec}) 

1503 Right-Code : = Render-Code | Transport-Code | File-Management- 

Code| Derivative-Works- Code | Configuration-Code 
1 504~Render-Code : = [ Play : {Player: Piayer-ED} | Print: {Printer: Printer-ID}] 

1 505— Transport-Code : = [Copy | Transfer | Loan {Remaining-Rights: 
Next-Set-of-Rights}]{(Next-Copy-Rights:Next-Set-of-Rights)} 

1 506 — - File-Management-Code : = Backup {Back-Up-Copy-Rights: 

Next-Set-of-Rights} | Restore | Delete | Folder 
| Directory {Name: Hide-Local | Hide-Remote} 
{Parts: Hide-Local | Hide-Remote} 

1 507— Derivative-Works-Code : = [Extract | Embed | Edit{Process: 

Process-ID}] {Next-Copy-Rights : 
Nert-Set-of Rights} 

1508 Configuration-Code : = Install | Uninstall 

1 509— Next-Set-of-Rights : = {(Add: Set-Of-Rights)} {(Delete: 
Set-Of-Rights)} {(Replace: Set-Of-Rights )K(Keep: Set-Of-Rights )} 

1510 — Copy-Count : = (Copies:positive-integer 1 0 1 Unlimited) 
1511 — -Control-Spec : = (Control: {Restrictable | Unrestrictable} 

{Unchargeable | Chargeable}) 
7572— Time-Spec : = ({Fixed-Interval | Sliding-Interval | Meter-Time} 

Until: Expiration-Date) 

1513 — - Fixed-Interval : = From: Start-Time 

1 51 4 — Sliding-Interval : = Interval: Use-Duration 

1 515 — Meter-Time: = Time-Remaining: Remaining-Use 

1516 — Access-Spec : = ({SC: Security-Class} {Authorization: Authorization-ID*} 
{Other-Authorization: Authorization-ID*} {Ticket: Ticket-ID}) 

1 51 7- ^Fee-Spec: = {Scheduled-Discount} Regular-Fee-Spec | Scheduled-Fee-Spec | 

Markup-Spec 

1518 — Scheduled-Discount: = Scheduled-Discount: (Scheduled-Discount: 

(Time-Spec Percentage)*) 

151 9— Regular-Fee- Spec := ({Fee: | Incentive: } [Per-Use-Spec | Metered-Rate- 

Spec | Best-Price-Spec | Call-For-Price-Spec] 
{Min: Money-Unit Per: Time-SpecKMax: 
Money-Unit Per: Time-Spec} To: Account-ID) 
1 520-— Per-Use-Spec: = Per-Use: Money-unit 

1521 — Metered- Rate-Spec : = Metered: Money-Unit Per: Time-Spec 

1522 — Best-Price-Spec : = Best-Price: Money-unit Max: Money-unit 

1 523— Call-For-Price-Spec := Call-For -Price 

7524— Scheduled-Fee-Spec: = (Schedule: (Time-Spec Regular-Fee-Spec)* ) 
1525 — Markup-Spec: = Markup: percentage To: Account-ID 

Fig.1S 
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